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
