On Tue, Jul 28, 2015 at 10:05 PM, Viktor Dukhovni <ietf-d...@dukhovni.org>
wrote:
> On Tue, Jul 28, 2015 at 09:44:34PM -0400, Shumon Huque wrote:
>
> This is no longer the DNS response to a single query (iterative
> resolvers generally chase CNAMEs), since one first CNAME expands
> the original target hostname to obtain the TLSA base domain (provided
> the CNAME chain is validated end-to-end) and then CNAME expands
> the _443._tcp. prefixed base domain to find the TLSA RRset.
>
Hmm, I guess the DANE ops draft says to look for TLSA records at the alias
target rather than the owner name. This doesn't seem to be how many early
HTTPS sites are deploying TLSA records though, e.g. www.ietf.org.
> the getdns library's validation chain function currently returns (RRSIGs
> > omitted for brevity):
> >
> > _443._tcp.www.example.com. CNAME
> > ca.example.net. TLSA <set>
> >
> > example.com. DNSKEY <set>
> > example.com. DS <set>
> > com. DNSKEY <set>
> > com. DS <set>
> > . DNSKEY
> > example.net. DNSKEY <set>
> > example.net. DS <set>
> > net. DNSKEY <set>
> > net. DS <set>
>
> The getdns library is unlikely to handle the fully general case,
> because first the TLSA base domain has to be found.
>
It probably doesn't today. I'll check into this.
> > It looks like that draft proposes SCT RRs (with DS+chain data in them,
> > signed by log providers), so we could in the future incorporate SCT RRs
> in
> > the chain. However do we really need to? The TLS server is the one doing
> > the DNS queries, so it could perform the SCT checks against the logs it
> > trusts, while querying the chain records, and then build the validated
> > chain. I'm not sure there is a need for the TLS client to additionally do
> > these log checks, so it doesn't need to have that info delivered in the
> > chain.
>
> The TLS server is not trusted, the whole point is detect malfeasance,
> where the DNS operator and TLS server conspire to lie (to selected
> clients).
>
Yeah, I had a feeling you'd say this :-) Fair enough, that's an additional
threat we should take into account.
> > > This really can't go in the certificate, because then certificates
> > > would have to be updated as often as RRSIGS are regenerated. That
> > > seems exceedingly unlikely to be deployable.
> > >
> >
> > I believe Eric's question was about why this couldn't be done via a new
> > 'Certificate Type' (and not about embedding the chain in the X.509
> cert). I
> > presume the idea being the new certificate type would allow both the
> > server's X.509 certificate chain and the corresponding DANE/DNSSEC chain
> to
> > be delivered in the server's Certificate Message. I believe the argument
> > for doing it via a new TLS extension was that it would allow us to
> mandate
> > the use of the DANE chain ("Must staple DANE") via the X.509 TLS Feature
> > Extension.
>
> I see. I think the question of whether "must staple DANE" is
> supported or not is quite orthogonal to the question of how DANE
> stapled data is encoded.
>
Encoded yes, but not necessarily on what protocol element carries the
encoding. It depends on what mechanism is being used for the must-staple
assertion. The X.509 TLS feature extension mechanism requires a list of TLS
extension values to be specified. Using a new TLS certificate type would
not be compatible with that.
The disadvantage of this being a new certificate type is that AFAIK
> it would then not be orthogonal to the choice between X.509 chains
> and raw public keys. We might then have a (small) combinatorial mess:
>
> traditional X.509 chain
> X.509 chain with stapled DANE evidence
> raw public key
> raw public key with stapled DANE evidence
>
> I think the extension is a more logical separation of duties, but
> I am willing to hear contrary arguments.
>
Yes, I agree.
Shumon Huque.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
