Be aware that there are two authors listed in RFC 6844 which is the rfc for CAA. Both are Comodo employees. There are no other authors listed.
Therefore, Comodo has a more than casual interest, and less than impartial viewpoint when answering questions from you about CAA.
– [Spenser]
I checked the RFC and indeed, both listed authors seem to be from Comodo at the time of writing the RFC.
Internet Engineering Task Force (IETF) P. Hallam-Baker Request for Comments: 6844 Comodo Group, Inc. Category: Standards Track R. Stradling ISSN: 2070-1721 Comodo CA, Ltd. January 2013
You might also look at the history of the voting to impose the September deadline. The voters were members of some committee of browser and certificate vendors. There was seemingly no input from people involved in DNS. Since CAA is a DNS record, that is somewhat odd. Create a dependency on something where the provider of that thing has not been consulted, and where the provider of that thing has to write new code in order for the new thing to actually exist.
If you look at the scheme carefully, it offers nothing more than operational convenience for the issuer.
First, a CAA record need not exist. The issuer must query for the record, but it need not exist. This is often glossed over and has caused much consternation when it is presented as a requirement. The only requirement is that the issuer query for the record, and comply with the content of the record, if it exists.
Second, it offers no real protection against improperly issuing a certificate to a non-authorized person in its normal usage. If a CAA record is published that specifies xxx.com as the only authorized issuer, then a non-authorized person only needs to be sure to buy their certificate from xxx.com instead of any other certificate issuer. There is a provision for setting the contact name and notifications, but this will be unlikely to be widely used or understood.
– [Spenser]
I found an description of the DNS Certification Authority Authorization and its current state. The so called “CA/Browser Forum”, where Comodo is a member, voted for the CAA in Ballot 125 from 2014-10-14. In this vote, the decision for the CAA resource record was made.
In March 2017 the CA/Browser Forum voted (Ballot 187 from 2017-05-08) to make CAA mandatory. As of this, beginning with September 2017 (six months after the vote), all CAs should honor the CAA records.
Interestingly, in the list of exceptions is the following point:
CAA checking is optional if the CA or an Affiliate of the CA is the DNS Operator (as defined in RFC 7719) of the domain’s DNS.
– [Ballot 187 – Make CAA Checking Mandatory]
So, if the CA is also in charge of the domain’s DNS, or one of their affiliates, they can skip the check of CAA records set by the domain owner. So if Cloudflare would allow CAA records and Comodo would have a contractual partnership (an affiliation), they are allowed to ignore the CAA records. Personally, I think these exceptions make the whole concept of CAA records not completely useless, but at least not trustworthy, as you never know if the CAA records will be checked or not.
Additionally, as Spencer mentioned, the CAA records as such do not avoid unauthorized creation of certificates at all. They might make it a bit harder to achieve it as they have to be from the same CA, but as I understood the CAA specification, anyone who is able to successfully validate a domain with a CA could simply request the certificate from the CA listed in the CAA record.
Again, a big thank you to Spencer for the detailed insight which pointed me in this direction.
]]>Similarities and differences
While Type2Phone stays connected for some time even if you leave the application, Typeeto disconnects from the devices as soon as you switch away from it. It is hard to say if that is a good or bad thing.
Apple iOS devices hide the on screen keyboard as long as a bluetooth keyboard is connected. With Type2Phone, the keyboard stays hidden for some time until the application disconnects. During that time you can not use the on screen keyboard unless you explicitly disconnect the application from the device. With Typeeto you don’t have to do this as it disconnects as soon as you switch to another application. The downside of this approach is the connect time. Switching a lot between Mac applications and Typeeto causes a lot of connects and disconnects – and the connect takes a couple of seconds each time.
In comparison, Typeeto shows a very neat UI providing only the details needed. Sadly, it misses a few features I really like in some of the others. While writing, I missed the possibility to navigate text quickly as it is a bit more challenging as Typeeto does not yet support all the keyboard features.
Select text with the keyboard
Typeeto allows to use the keyboard shortcuts
Jump to the beginning / end of a line / word by word
Navigating text can be painful without navigation shortcuts like jumping to the start or the end of a line. The same for jumping the cursor word-by-word. All those shortcuts are standard behaviour of a mac and would be possible on mobile devices as well. Sadly those shortcuts are not yet supported by Typeeto.
Even if Typeeto is not supporting all the features provided by other solutions, it surprises in other features.
Copy/paste from the Mac to the device
The approach for copy/paste across devices is great. While others provide a way to copy text from the Mac to the device as well, they force you to interact with the UI in some way. Typeeto allows you to configure a separate keyboard shortcut to paste the Mac’s clipboard to the connected device. With this shortcut set, you can keep your hands on the keyboard while you copy text between your Mac and the connected device.
All those features are supported by iOS Apps and work through Type2Phone. Sadly they do not work yet via Typeeto. Those are features you only notice missing if you use Typeeto to edit bigger pieces of text.
All in all, a very neat application which works great as a bluetooth keyboard. And even if it misses a few features, it has great potential.
]]>I’ve been tinkering with CentOS for a year or so, having used Ubuntu previously. I’ve tried to set up secure server (a VM at home) and came to the point where I wanted to add mail provision. There are countless online tutorials and, whilst most of them got me to 95% of where I wanted to be, it wasn’t until I stumbled upon your series (with the detailed testing processes) that I nailed secure Postfix! The only thing I had to add was the creation of a self-signed certificate and, fortunately, I had found a very good article which supplemented yours and covered this in detail. I haven’t had chance to do anything with Dovecot yet but am confident that your article will hold my hand down that path!
As well as congratulating you, the other reason for writing is to mention the recently publicised Logjam attack. I seem to recall somewhere on your site you mentioned that comments had been disabled because of the amount of spam, otherwise I would have posted there. I don’t know if you might consider an addendum to one of the mailserver articles (maybe the one dealing with hardening the SSL configuration) or a separate article dealing with the Logjam attack and how to mitigate against it. Here are some links that I found:
Weak Diffie-Hellman and the Logjam Attack
Guide to Deploying Diffie-Hellman for TLS
I’ll keep an eye on your blog as the articles are well written and relevant to my interests.
Iain
]]>ProxyCommand ssh Server1 nc %h %p
This uses the netcat (nc) command, but actually plain ssh can be used to
achieve the same thing. SSH provides the “-W” option for this. The ProxyCommand
line then looks like this.
ProxyCommand ssh Server1 -W %h:%p]]>
thanks for you blog, i really like it. It’s clean and easy to overlook.
One hint:
If “dd” is at work, you can easily press “STRG+T“ and it will print the current status for you.
Regards,
Chris
While Mac OS X 10.7 (Lion) allows you to execute the “dd” command with your user priviledges, Mavericks does not.
So if you are using Mavericks and get the “Permission” error, the solution is to use sudo. Sudo allows you to run the “dd” command with root priviledges. While the root user is disabled in Mac OS X by default, sudo is allowed for users which have the “Allow user to administer this computer” option set.
When using sudo as shown below, you will be asked for your password to proceed.
$ sudo dd if=destination_file.img.dmg of=/dev/disk2 bs=1m
Please keep in mind that after you have entered the password, the dd command does not show any output. So please be patient until the dd command has finished.
Thanks again to John for pointing this out!
]]>