Re: [TLS] Interim meeting information

[Viktor Dukhovni <[e-mail]>]

> On Sep 12, 2018, at 10:58 AM, Christopher Wood <[e-mail]> wrote:
> 
> Below is an agenda for Friday's virtual interim meeting, followed by
> the meeting information. This information is also available online
> [1]. We are looking for volunteers to lead each agenda item. Please
> respond on list or to the chairs directly if you're willing to do so.
> 
> Best,
> Chris, Joe, and Sean
> 
> [1] https://datatracker.ietf.org/doc/agenda-interim-2018-tls-01-tls-01/
> 
> ~~~
> 
> Agenda: Discuss draft-ietf-tls-dnssec-chain-extension
> - Problem statement recap.
> - Discuss client-side caching semantics and use cases.
> - Discuss need (or not) for extension pinning.
> - Review some open gaps:
>  - Lack of a port number in the client side of the extension.
>  - Lack of downgrade protection for existing applications.
>  - Lack of discussion of virtual hosting.
>  - Needless complexity from RRset ordering requirements.

Thanks.  There are a couple of other gaps that'll come to the surface
once we get down to work updating the text.  One issue is that draft-07
did not require SNI from the client, and seemed to suggest that the
server can in any case use the extension with some default name, even
when it does not recognize the client's SNI.  This does not work at
all well.

I've prepared text that makes SNI a co-requisite with dnssec_chain,
and ensures that the server's extension matches the requested SNI
or else the server decline the dnssec_chain extension.

Denial of existence text needed a bit more polish, ...  Also
added some commentary on the need for NSEC records any time
something in the chain is synthesized via wildcard records.
(Some the background discussion is the git commit message).

When we actually get to discuss virtual hosting use-cases it'll
be useful point out a deviation from RFC7671, which suggests
CNAME chasing that simply can't be made to work with dnssec_chain,
(and that's OK).

I've also realized that even with direct DNS lookups the CNAME chasing
in RFC7671 is not a good fit for some applications (like web browsers)
where the server's post-handshake behaviour depends on the SNI
value.  It seems that 7671 had a bit too much SMTP tunnel-vision, ...
sorry about that.  So we could even consider a couple of updates
to 7671 here, or in a separate draft.  Perhaps the UKS draft from
Richard Barnes could get adopted and also fix-up the CNAME
issues from 7671.

-- 
	Viktor.