Re: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04

[Ilari Liusvaara <[e-mail]>]

On Tue, Jul 04, 2017 at 12:14:42PM -0400, Viktor Dukhovni wrote:
> 
> > On Jul 4, 2017, at 11:33 AM, Shumon Huque <[e-mail]> wrote:
> > 
> > Yes, in fact the previous sentence to the one you quoted did say this more or less: " ... return a serialized authentication chain in the Certificate message associated with the end entity certificate being validated ". I would propose rewording that a bit and removing the last quoted sentence entirely:
> > 
> >    Servers receiving a "dnssec_chain" extension in the ClientHello, and
> >    which are capable of being authenticated via DANE, SHOULD return a
> >    serialized authentication chain in the extension block of the Certificate 
> >    message containing the end entity certificate being validated, using the 
> >    format described below.
> 
> Why the end-entity certificate, and not the final certificate
> sent by the server?  With anything but DANE-EE(3) the TLSA
> records can't be processed against the server's certificate
> message until *all* the server certificates have been received.

Well, the optimal would be the certficiate record pertrains to.
However, since RRsets are atomic, this is not possible.
 
> So instead of squirreling away the DNS data while waiting for
> all the server certificates to arrive, it may make more sense
> to receive the TLSA records (and associated signatures, CNAMEs,
> DNAMEs, ...) once all the server certificates have been received.
> 
> Of course either way one still buffers all the server certificates,
> so buffering the TLSA records is not a major issue.  It's just that
> I don't see a compelling argument for sending the TLSA records with
> the EE certificate.  Perhaps send them with any of the server
> certificates, it probably makes no difference which...

The entiere Certificate message should be loaded into memory anyway.
And one definitely does not want to merge records.


-Ilari