On Wed, Feb 21, 2018 at 12:51 PM, Eric Rescorla <e...@rtfm.com> wrote:
> > > On Wed, Feb 21, 2018 at 7:52 AM, Shumon Huque <shu...@gmail.com> wrote: > >> >> My comment was about what DANE mode choices the server is offering to >> the client. Certainly, the client can decide whether it wants to use >> DANE or not, and whether it wants to fallback to PKIX. The protocol >> should probably not be proscriptive here, and allow different TLS >> applications (or configurations of such applications) to make choices. >> But maybe there are some general recommendations to be made. >> > >> One additional comment about PKIX fallback on DANE failure: If a >> server is using DANE-EE or DANE-TA, it has the ability to send back >> a much shorter Certificate message - just the EE certificate for the >> former, and typically a very short X.509 chain for the latter. But >> this means that for fallback to PKIX, the client would have to start >> a new handshake omitting the dnssec_chain extension. For efficient >> fallback within the same handshake, the server would always have to >> send back the full PKIX X.509 chain. Maybe that's what we need to >> recommend for servers that support both DANE and traditional PKIX. >> > > That would be my proposal, but I think at least you need to provide the > kind of analysis you do here. > Okay, I'll include that analysis and recommendation. >> > > 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 >> > > > Why is this a SHOULD where the corresponding reqt for TLS 1.2 and >> below >> > > is a >> > > > MAY? >> > > >> > > They should clearly be consistent. My preference would be "SHOULD" for >> > > both. >> > > >> > >> > That's a WG decision. >> >> Ok. Let me know how you want to handle this question. I'd be happy to >> send a separate note to the WG list about it. >> > > Sorry, I didn't mean to discount your view. I meant that I didn't think it > was > role to say which one it should be. > > This is actually a question for the chairs and the AD (Kathleen). If they > think the > WG decided this, then you can just do "SHOULD". If they think it requires > WG > consultation, then you should do that > Ok. > > > > the draft is adopted by the WG, the authors expect to make an >> early >> > > > allocation request as specified in [RFC7120]. >> > > > Do you want this to be marked RECOMMENDED? >> > > >> > > In response to Mirja's earlier comment, I think we are taking out this >> > > sentence. >> > > >> > >> > You're still registering the code point, so you need to determine if >> it's >> > RECOMMENDED or not. >> >> Sorry for being dense - this protocol requires a new codepoint. Do we >> need to say we RECOMMEND that a new code point be registered? >> >> Or are you asking that we RECOMMEND that IANA allocates our preferred >> extension type value (53)? >> > > No. There is a column in the code point assignment for IANA that says > whether the IETF recommends the use of this extension or whether we're > just assigning the code point but don't recommend it. So you need to say > which one it is. I assume the WG wants "Recommended" > Ah, got it. Since the WG adopted this document, "Recommended" would be my assumption too. I'll start making edits based on issues/comments raised in this thread in the github repo, if folks want to follow along, and/or participate: https://github.com/tlswg/dnssec-chain-extension I'll circle back on list when it's ready for review .. Shumon.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls