Subject: [TLS] Ben Campbell's Yes on draft-ietf-tls-tls13-26: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Tue, 06 Mar 2018 09:27:42 -0800

Ben Campbell has entered the following ballot position for
draft-ietf-tls-tls13-26: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

There has clearly been a lot of work put into this. It's a surprisingly
understandable document, given its length and the complexity of the subject. I
am balloting yes, but I have a few minor comments and nits. None of these are
showstoppers, so please do with them as you will.

*** Substantive Comments:

§4.1.2, first paragraph: " When a client first connects to a server, it is
REQUIRED to send the
   ClientHello as its first message. "

Is that intended to prohibit the use of STARTTLS or similar application layer
patterns? (To be clear, this is not an objection, just a clarification request.)

§4.1.2, legacy_compression_methods: "Note that TLS 1.3 servers might receive
TLS 1.2 or prior
      ClientHellos which contain other compression methods and MUST
      follow the procedures for the appropriate prior version of TLS."

Is that intended to require TLS 1.3 servers to always be willing and able to
negotiate 1.2? §4.2.1 has a similar assertion:

"If this extension is not present, servers which are compliant with
   this specification MUST negotiate TLS 1.2 or prior as specified in
   [RFC5246], even if ClientHello.legacy_version is 0x0304 or later."

But §4.2.3 says:

 "Note that TLS 1.2 defines this extension differently.  TLS 1.3
   implementations willing to negotiate TLS 1.2 MUST behave in
   accordance with the requirements of [RFC5246] when negotiating that
   version."

... which seems inconsistent (noting that this paragraph talks about
"implementations" rather than "servers", so perhaps there's a subtle difference?

§4.2.1.1: The section is marked for removal. Do you expect that RFC
implementations will ever need to interop with draft implementations? If so,
the information in this section may continue to be useful for some time.

§D.5: This section has a lot of normative requirements that seem important. I
wonder why it has been relegated to an appendix.

*** Editorial Comments and nits:

§2: "If (EC)DHE key establishment
   is in use, then the ServerHello contains a "key_share" extension with
   the server’s ephemeral Diffie-Hellman share which MUST be in the same
   group as one of the client’s shares. "

missing comma prior to "which".

§4.1.1: "Note that if the PSK can be used without (EC)DHE then non-
   overlap in the "supported_groups" parameters need not be fatal, as it
   is in the non-PSK case discussed in the previous paragraph."

I read "need not be fatal" to mean that it may still be fatal at times. Is that
the intent?

§11: The IANA considerations have a number of constructions similar to "SHALL
update/has updated". Is that text expected to collapse to "has updated" at some
point?

§E.2.1: [BDFKPPRSZZ16]  : Best citation anchor evar

---

From: Sean Turner <[email-masked]>
Date: Wed, 7 Mar 2018 15:49:54 -0500

> On Mar 6, 2018, at 12:27, Ben Campbell <[email-masked]> wrote:
> 

No - this is just how it works TLS - clients send the ClientHello message first ;)

> "implementations" rather than "servers", so perhaps there's a subtle difference?

In short kinda, sorta yes: §s4.2.1 includes the following:

   Implementations of TLS 1.3 which choose to support prior versions of
   TLS SHOULD support TLS 1.2.

Not sure it’s inconsistent given that the 2nd quote is about the server needs to do with the information it’s getting from the client.

> the information in this section may continue to be useful for some time.

I think it’ll be useful for about as long as it takes for them to rev their code bases, which I am sure hoping is faster than the 6 or so weeks it’ll take for this draft to get to through the RFC editor’s queue.

> wonder why it has been relegated to an appendix.

§D.5 is about backward compatibility and though we negotiations with 1.2 is a SHOULD we say nada about earlier versions.  And, we don’t want to say anything about earlier versions.   And, some of this is technically repeated from other RFCs, eg. 5768 and 6176 saying don’t do SSL2/3. So, it ended up in an appendix.

> missing comma prior to "which”.

(grammar police are banging on my door as we speak)
So is the which clause restrictive or non restrictive?  I’m going with this this clause being restrictive (hence no comma).

> I read "need not be fatal" to mean that it may still be fatal at times. Is that

Yes that is the intent.

> update/has updated". Is that text expected to collapse to "has updated" at some

Yes - once we’ve gotten the a-okay from IANA, well as the RFC editor to make it just say “has updated” etc.

> §E.2.1: [BDFKPPRSZZ16]  : Best citation anchor evar

:)

---

From: Ben Campbell <[email-masked]>
Date: Wed, 7 Mar 2018 15:35:33 -0600

> On Mar 7, 2018, at 2:49 PM, Sean Turner <[email-masked]> wrote:
> 
> 
> 

I assume your response to mean that the point is merely that ClientHello is the first message of the TLS handshake. As worded, I think some readers might interpret this to mean that the client can send no other data at any layer prior to ClientHello.

>   TLS SHOULD support TLS 1.2.

That still says “which choose to support”

> Not sure it’s inconsistent given that the 2nd quote is about the server needs to do with the information it’s getting from the client.

I’m still confused. Is the server allowed to refuse to negotiate 1.2? Or is the exception in §4.2.1 supposed to apply to all of the related MUSTs?

> I think it’ll be useful for about as long as it takes for them to rev their code bases, which I am sure hoping is faster than the 6 or so weeks it’ll take for this draft to get to through the RFC e…

Okay.

> §D.5 is about backward compatibility and though we negotiations with 1.2 is a SHOULD we say nada about earlier versions.  And, we don’t want to say anything about earlier versions.   And, some of t…

Okay.

> (grammar police are banging on my door as we speak)

Well, my comment was labeled as editorial or nit :-)

> So is the which clause restrictive or non restrictive?  I’m going with this this clause being restrictive (hence no comma).

I’ll let the grammar police at your door debate the merits of “which” vs “that” for restrictive clauses :-)

>> I read "need not be fatal" to mean that it may still be fatal at times. Is that

Okay. Would it be reasonable to offer guidance about when might want to treat this as fatal even though it would have been possible to use the PSK without (EC)DHE?

> Yes - once we’ve gotten the a-okay from IANA, well as the RFC editor to make it just say “has updated” etc.

Okay.

>> §E.2.1: [BDFKPPRSZZ16]  : Best citation anchor evar

I am trying to decide if that should sound like a “Bill the Cat” utterance or a sound effect for cartoon violence involving high voltage :-)

---

From: Sean Turner <[email-masked]>
Date: Wed, 7 Mar 2018 19:39:48 -0500

> On Mar 7, 2018, at 16:35, Ben Campbell <[email-masked]> wrote:
> 
> 
> 

Well this is about TLS :) But, maybe r/its first message/its first TLS handshake message ?

> That still says “which choose to support”

Right so there might be some implementations that choose to not support prior versions.

> I’m still confused. Is the server allowed to refuse to negotiate 1.2? Or is the exception in §4.2.1 supposed to apply to all of the related MUSTs?

Yes - TLS servers are allowed to refuse to negotiate earlier version; that’s deciding to not follow the SHOULD in  §s4.2.1.  If they negotiate an earlier version then do that version that’s what’s in §s4.1.2 and in §4.2.3.

> I’ll let the grammar police at your door debate the merits of “which” vs “that” for restrictive clauses :-)

See the response to Adam’s comment :). But, yeah the RFC editor will definitely school me when the time comes.

> Okay. Would it be reasonable to offer guidance about when might want to treat this as fatal even though it would have been possible to use the PSK without (EC)DHE?

So the fatal error is when the client and server are trying to negotiate (EC)DHE parameters and there’s no overlap in the supported_groups.  This would occur in the “normal” case when the client is anonymous (i.e., client only sends ClientHello+key_share and no psk_key_exchange_modes/pre_shared_key) or when the client is using PSK+(EC)DHE for client authentication.  But, that is described in the previous paragraph.  Maybe another way to say it is: normally you’d throw an error if supported_groups didn’t overlap, but here since you’re not using them because you’re doing PSK-only you don’t.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 7 Mar 2018 17:47:20 -0800

On Wed, Mar 7, 2018 at 4:39 PM, Sean Turner <[email-masked]> wrote:

> > I assume your response to mean that the point is merely that ClientHello
> is the first message of the TLS handshake. As worded, I think some readers
> might interpret this to mean that the client can send no other data at any
> layer prior to ClientHello.
>

Indeed, I am aware of at least one.

-Ekr

>
> >> Not sure it’s inconsistent given that the 2nd quote is about the server
> needs to do with the information it’s getting from the client.
> >
> > I’m still confused. Is the server allowed to refuse to negotiate 1.2? Or
> is the exception in §4.2.1 supposed to apply to all of the related MUSTs?
>
> Yes - TLS servers are allowed to refuse to negotiate earlier version;
> that’s deciding to not follow the SHOULD in  §s4.2.1.  If they negotiate an
> earlier version then do that version that’s what’s in §s4.1.2 and in §4.2.3.
>
> >> I think it’ll be useful for about as long as it takes for them to rev
> their code bases, which I am sure hoping is faster than the 6 or so weeks
> it’ll take for this draft to get to through the RFC editor’s queue.
> >
> > Okay.
> >
> >>
> >> §D.5 is about backward compatibility and though we negotiations with
> 1.2 is a SHOULD we say nada about earlier versions.  And, we don’t want to
> say anything about earlier versions.   And, some of this is technically
> repeated from other RFCs, eg. 5768 and 6176 saying don’t do SSL2/3. So, it
> ended up in an appendix.
> >
> > Okay.
> >
> >>
> >> So is the which clause restrictive or non restrictive?  I’m going with
> this this clause being restrictive (hence no comma).
> >
> See the response to Adam’s comment :). But, yeah the RFC editor will
> definitely school me when the time comes.
>
> > Okay. Would it be reasonable to offer guidance about when might want to
> treat this as fatal even though it would have been possible to use the PSK
> without (EC)DHE?
>
> So the fatal error is when the client and server are trying to negotiate
> (EC)DHE parameters and there’s no overlap in the supported_groups.  This
> would occur in the “normal” case when the client is anonymous (i.e., client
> only sends ClientHello+key_share and no psk_key_exchange_modes/pre_shared_key)
> or when the client is using PSK+(EC)DHE for client authentication.  But,
> that is described in the previous paragraph.  Maybe another way to say it
> is: normally you’d throw an error if supported_groups didn’t overlap, but
> here since you’re not using them because you’re doing PSK-only you don’t.
>
> > I am trying to decide if that should sound like a “Bill the Cat”
> utterance or a sound effect for cartoon violence involving high voltage :-)
> >
> >>
> >
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 9 Mar 2018 14:15:25 -0800

Following up.

> §4.1.2, first paragraph: " When a client first connects to a server, it
is REQUIRED to send the
> Is that intended to prohibit the use of STARTTLS or similar application
layer patterns?
> (To be clear, this is not an objection, just a clarification request.)

This was clarified.

> §4.1.2, legacy_compression_methods: "Note that TLS 1.3 servers might
receive TLS 1.2 or prior
> Is that intended to require TLS 1.3 servers to always be willing and able
to negotiate 1.2? §4.2.1

We clarified this text.

> has a similar assertion:

I added a clarification here.

> ... which seems inconsistent (noting that this paragraph talks about
"implementations"
> rather than "servers", so perhaps there's a subtle difference?

The extension was relevant for clients and servers in TLS 1.2.

> §4.2.1.1: The section is marked for removal. Do you expect that RFC
implementations
> will ever need to interop with draft implementations? If so, the
information in this section
> may continue to be useful for some time.

RFC implementations don't interop with draft implementations in any
meaningful way. I.e., they just negotiate TLS 1.2.

>
> §D.5: This section has a lot of normative requirements that seem
important. I wonder why it has been
> relegated to an appendix.o

Because they are levies in the non-TLS 1.3 portions of the imp.

> missing comma prior to "which".

I made a slightly different change.

> I read "need not be fatal" to mean that it may still be fatal at times.
Is that the intent?

Yes. Suppose you could only use the PSK with ECDHE. That's what the "if the
PSK can be used..."
is about.

> §11: The IANA considerations have a number of constructions similar to
"SHALL update/has updated".
> Is that text expected to collapse to "has updated" at some point?

Yes. RFC-Ed typically does this.

-Ekr

On Wed, Mar 7, 2018 at 5:47 PM, Eric Rescorla <[email-masked]> wrote:

>> > I assume your response to mean that the point is merely that
>> ClientHello is the first message of the TLS handshake. As worded, I think
>> some readers might interpret this to mean that the client can send no other
>> data at any layer prior to ClientHello.
>>
>> >> Not sure it’s inconsistent given that the 2nd quote is about the
>> server needs to do with the information it’s getting from the client.
>> >
>> > I’m still confused. Is the server allowed to refuse to negotiate 1.2?
>> Or is the exception in §4.2.1 supposed to apply to all of the related MUSTs?
>>