On Tue, Jul 30, 2013 at 01:22:43PM +0200, Ond?ej Sur? wrote:
> 1. the high/low bit part in "2. DANE TLSA record overview".
>
> Please drop/rewrite the bit part since it will become confusing when we
> adopt draft-ietf-tls-oob-pubkey for DANE.
Since we only discuss usages 0-3, perhaps the "bit part" can be restricted
to cover just those 4 usages. Clearly usages 4 and up are likely to break
the pattern. Or we can change the wording. It really is not important
that the feature matrix for 0-3 is bit-aligned.
By the way, is there any reason to adopt a new usage for bare public
keys? What's wrong with "3 1 1"? Existing TLSA associations that
match public keys inside an EE certificate can equally match public
keys that are not inside a certificate.
> 2. Section 3.5 on CNAMES
>
> The recommendation to follow the CNAME chain and do hop-by-hop
> checks won't work with most used protocol - HTTPS. Generally you
> expect an TLS certificate for "www.iamconnecting.to" and not for
> "server.provider.srv" as suggested by the draft.
What may be missing from the draft, but was intended to be there,
is a fallback to the initial name when no TLSA RRs are found at
the CNAME expanded target. Certainly, for example, when the final
target is in an insecure zone (prime example from Wes: www.paypal.com).
If however, there is a TLSA RRset on the right side of a secure
alias, it makes sense to use that in preference to the initial
name. As explained loudly in the POSH BOF on Monday, key sharing
with SNI is not for everyone, and finding a way to use the provider's
keys securely is far better.
In effect all that POSH is trying to do is a secure redirect, but
in a complicated ad-hoc manner via PKIX HTTPS servers. That's a
bit lame IMHO. But they are identifying a real need to get past
SNI. If we model the old world of HTTPS too closely, we capture
its unintended faults (no CNAME chasing and hence SNI, because
without DNSSEC CNAMEs are MITM vulnerable) as well as its useful
features.
There is no axiom that HTTPS secure names must be what the user
typed. It is just that's all that was possible previously. With
DNSSEC+DANE we *can* do better (obviate SNI and solve the issue
that motivates POSH).
Also keep in mind that the browsers seem to be the least likely to
implement DANE any time soon. Basing DANE on the application least
likely to adopt it seems a bit perverse.
Anyway, I'll be in the chat room on Thursday, I am hoping Wes will
cover this issue in detail.
> Also checking for CNAME means that the DANE PKI client would have
> to (re-)implement whole follow-the-CNAME login instead of using
> simple getaddrinfo().
They already need a DNS API. This is not a big deal.
> So I am not sure if this is a sensible default.
It is certainly worthy of discussion! But I would point out the
POSH BOF as a strong signal that dealing with hosting is a very
important issue. For protocols with SRV (and SRV-like MX, ??)
records indirection is already largely dealt with. I wanted to
make CNAMEs behave like poor-man's SRV records and deliver the same
benefit. That's is allow the client to discover the hosting
provider's name! Thereby avoiding the pain and suffering of SNI.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
