Re: [TLS] WGLC: draft-ietf-tls-tls13-19

[Eric Rescorla]

On Tue, Apr 11, 2017 at 11:27 AM, Benjamin Kaduk  wrote:
>
> Yeah, I guess I snuck that fix into #936.  So much for keeping things
> separate...
>
> > Page 113 still has the “[[NOTE: TLS 1.3 needs a new channel binding
> > definition that has not yet been defined.]]”, which should not make it
> > into the final spec!
>
> Fixed.
>
>
> It looks like that was just by removing the note.  Is a channel binding
> spec for 1.3 still a needed work item, then
>

Yeah, I think so.

-Ekr


>
> -Ben
>
>
>
> On Mon, Mar 27, 2017 at 11:23 PM, Kaduk, Ben  wrote:
>
>> On 3/13/17, 12:30, "Sean Turner"  wrote:
>>
>> This is a working group last call announcement for
>> draft-ietf-tls-tls13-19, to run through March 27.  Please send your reviews
>> to the list as soon as possible so we can prepare for any discussion of
>> open issues at IETF 98 in Chicago.
>>
>> As the price of running the WGLC right during the meeting lead-up, my
>> review comes in at the last minute.
>>
>> Generally, it is in good shape.  I think I still owe some text about what
>> we aim for and expect to achieve with respect to side channel resistance,
>> though at this point it may be too late to get that text in :(
>>
>> The following is basically a laundry list of the minor issues; I will
>> send editorial notes under separate cover, probably as a pull request.
>>
>> It was already mentioned that the “major differences from TLS 1.2”
>> section should not be a changelog, but I agree with that.
>>
>> Should Figure 4 (“message flow for a zero round trip handshake”) include
>> a “+ early_data” for the server’s flight?  (The legend for Figure 4 also
>> lacks the explanation for the ‘+’ symbol.)
>>
>> The language on page 30 is perhaps unclear:
>>
>>Because TLS 1.3 forbids renegotiation, if a server receives a
>>ClientHello at any other time, it MUST terminate the connection.
>>
>> Is that any TLS server, or just one that has negotiated and is using TLS
>> 1.3?
>>
>> In the description of legacy_compression_methods on page 31, we make
>> restrictions on “every TLS 1.3 ClientHello”, but do not say how such things
>> are identified.  (Hmm, maybe we also do so elsewhere in the document, too,
>> now that I search for where)  we explicitly define what a client
>> “considered to be attempting to negotiate using this specification (i.e., a
>> TLS 1.3 ClientHEello) on page 87, as supported_versions including 1.3.
>> Which, is maybe not the most future-proof thing.
>>
>> The description of version negotiation (to populate ServerHello.version)
>> on page 32 seems to leave undefined what the server should do when
>> receiving a ClientHello that does not contain a supported_versions
>> extension.  (Also, I don’t think “ClientHello.supported_versions
>> extension” is a well-defined syntax.)
>>
>> When covering the server_random version downgrade sentinels, we do not
>> mention what is to be done when downgrading to TLS 1.0, which I thought was
>> still a permitted version by this spec.
>>
>> It’s a little odd that we list in enum ExtensionType on page 35 a strict
>> subset of the extensions enumerated in the table on the following pages.
>>
>> Do we want to add some commentary about the extant SHA1 collisions when
>> we say that {rsa_pkcs1,dsa,ecdsa}_sha1 are only SHOULD NOT?
>>
>> I’ll note that we define 256 private use ECDHE group code points but only
>> four such FFDHE group code points.  Probably fine, but a bit surprising.
>>
>> Should we forbid duplicate entries in PreSharedKeyExtension.identities?
>>
>> Conversely, we might want to explicitly say that duplicate
>> OIDFilter.certificate_extension_oid fields should be expected in
>> OIDFilterExtensions, to enable the case where multiple values must be
>> present.  Or is that supposed to work by concatenating(?) the multiple
>> values’ DER encodings in the certificate_extension_values field?
>>
>> I’ll call out for Russ’s attention at the end of Section 4.4.3 where we
>> say that “implementations MUST NOT combine external PSKs with
>> certificate-based authentication.”  Is there any reason not to qualify that
>> as some sort of “don’t’ do it until it’s defined”?
>>
>> Should Alert.level be Alert.legacy_level?
>>
>> The editors copy has already removed the reference to RFC 4507, which is
>> obsoleted by RFC 5077 (and was not cited anywhere, anyway).
>>
>> Appendix B has a claim that “values listed as _RESERVED were used in
>> previous versions of TLS and are listed here for completeness”, though that
>> is not exactly true, e.g., for ContentType.invalid_RESERVED(0)
>>
>> Section C.3 notes that “Certificates should always be verified to ensure
>> proper signing by a trusted Certificate Authority”, which does not use RFC
>> 2119 language, but might be seen as in conflict with opportunistic
>> encryption in some circumstances.  I don’t object to this text, but it
>> seems worth mentioning.
>>
>> Page 113 still has the “[[NOTE: TLS 1.3 needs a new channel 

Re: [TLS] WGLC: draft-ietf-tls-tls13-19

[Benjamin Kaduk]

On 04/11/2017 12:32 PM, Eric Rescorla wrote:
> > It was already mentioned that the “major differences from TLS 1.2”
> > section should not be a changelog, but I agree with that.
>
> Yes, this is on my plate.
>
>
> > Should Figure 4 (“message flow for a zero round trip handshake”)
> > include a “+ early_data” for the server’s flight?  (The legend for
> > Figure 4 also lacks the explanation for the ‘+’ symbol.)
>
> I see you fixed this.
>

I guess I didn't consult back with what I had put in this mail when
preparing my editorial-changes pull request :)

>
> > The language on page 30 is perhaps unclear:
> > 
> >Because TLS 1.3 forbids renegotiation, if a server receives a
> >ClientHello at any other time, it MUST terminate the connection.
> > 
> > Is that any TLS server, or just one that has negotiated and is using
> > TLS 1.3?
>
> The latter. Adjusted.
>
>
> > In the description of legacy_compression_methods on page 31, we make
> > restrictions on “every TLS 1.3 ClientHello”, but do not say how such
> > things are identified.  (Hmm, maybe we also do so elsewhere in the
> > document, too, now that I search for where) we explicitly define what
> > a client “considered to be attempting to negotiate using this
> > specification (i.e., a TLS 1.3 ClientHEello) on page 87, as
> > supported_versions including 1.3.  Which, is maybe not the most
> > future-proof thing.
>
> I think I feel OK about this.
>

(For the gallery, there were some tweaks in this area in #936)

>
> > The description of version negotiation (to populate
> > ServerHello.version) on page 32 seems to leave undefined what the
> > server should do when receiving a ClientHello that does not contain a
> > supported_versions extension.  (Also, I don’t think
> > “ClientHello.supported_versions extension” is a well-defined syntax.)
>
> I think this clear in the section on Supported Versions.
>

It looks like this changed a little via #936 as well; I'm fine with your
followup change there.

>
> > When covering the server_random version downgrade sentinels, we do not
> > mention what is to be done when downgrading to TLS 1.0, which I
> > thought was still a permitted version by this spec.
>
> Interesting point. I'm trying to remember why we did things this way.
> I am tempted to just say "1.1 or 1.0". Thoughts?
>

That's probably fine; I expect there is some additional attack in there
where an attacker could force 1.0 if 1.1 would otherwise have been used,
but both of those are not in a great place right now, so we don't need
to try too hard to help them out.

>
>
> > Conversely, we might want to explicitly say that duplicate
> > OIDFilter.certificate_extension_oid fields should be expected in
> > OIDFilterExtensions, to enable the case where multiple values must be
> > present.  Or is that supposed to work by concatenating(?) the multiple
> > values’ DER encodings in the certificate_extension_values field?
>
> Yeah, I read this text as saying that those all go in the same
> DER, not that there can be multiple copies
>

Okay.

>
> > I’ll call out for Russ’s attention at the end of Section 4.4.3 where
> > we say that “implementations MUST NOT combine external PSKs with
> > certificate-based authentication.”  Is there any reason not to qualify
> > that as some sort of “don’t’ do it until it’s defined”?
>
> I'm actually going to move and modify this section per your issue #935.
>

Yeah, I missed the bits I called out in #935 when I was doing my WGLC
review, but the two are related and can be handled together.

>
> > Should Alert.level be Alert.legacy_level?
>
> i think we went over this and decided not to.
>

There was a pull request from not-me, yes.  Though IIRC it only changed
the name locally when describing alerts, and was rejected on the grounds
that "we don't use the legacy_level version for this anywhere else in
the spec", which is a little bit of circular reasoning.  I'm okay with
leaving it as-is.

>
> > Appendix B has a claim that “values listed as _RESERVED were used in
> > previous versions of TLS and are listed here for completeness”, though
> > that is not exactly true, e.g., for ContentType.invalid_RESERVED(0)
>
> I see you fixed this as well.
>

Well, maybe.  ContentType.invalid is the only one that I marked up in
red pen on my paper copy, but I can't certify that I compared the entire
list against the IANA registry.  I did look at the extensions registry
when preparing #936, though.

>
> > Section C.3 notes that “Certificates should always be verified to
> > ensure proper signing by a trusted Certificate Authority”, which does
> > not use RFC 2119 language, but might be seen as in conflict with
> > opportunistic encryption in some circumstances.  I don’t object to
> > this text, but it seems worth mentioning.
>
> I think the "Absent a specific..."
>
>

Yeah, I guess I snuck that fix into #936.  So much for keeping things
separate...

> > Page 113 still has the “[[NOTE: TLS 1.3 needs a new channel binding
> > definition that has not 

Re: [TLS] WGLC: draft-ietf-tls-tls13-19

[Eric Rescorla]

> It was already mentioned that the “major differences from TLS 1.2”
> section should not be a changelog, but I agree with that.

Yes, this is on my plate.


> Should Figure 4 (“message flow for a zero round trip handshake”)
> include a “+ early_data” for the server’s flight?  (The legend for
> Figure 4 also lacks the explanation for the ‘+’ symbol.)

I see you fixed this.


> The language on page 30 is perhaps unclear:
>
>Because TLS 1.3 forbids renegotiation, if a server receives a
>ClientHello at any other time, it MUST terminate the connection.
>
> Is that any TLS server, or just one that has negotiated and is using
> TLS 1.3?

The latter. Adjusted.


> In the description of legacy_compression_methods on page 31, we make
> restrictions on “every TLS 1.3 ClientHello”, but do not say how such
> things are identified.  (Hmm, maybe we also do so elsewhere in the
> document, too, now that I search for where) we explicitly define what
> a client “considered to be attempting to negotiate using this
> specification (i.e., a TLS 1.3 ClientHEello) on page 87, as
> supported_versions including 1.3.  Which, is maybe not the most
> future-proof thing.

I think I feel OK about this.


> The description of version negotiation (to populate
> ServerHello.version) on page 32 seems to leave undefined what the
> server should do when receiving a ClientHello that does not contain a
> supported_versions extension.  (Also, I don’t think
> “ClientHello.supported_versions extension” is a well-defined syntax.)

I think this clear in the section on Supported Versions.


> When covering the server_random version downgrade sentinels, we do not
> mention what is to be done when downgrading to TLS 1.0, which I
> thought was still a permitted version by this spec.

Interesting point. I'm trying to remember why we did things this way.
I am tempted to just say "1.1 or 1.0". Thoughts?


> It’s a little odd that we list in enum ExtensionType on page 35 a
> strict subset of the extensions enumerated in the table on the
> following pages.

This got fixed in PR#936.



> Do we want to add some commentary about the extant SHA1 collisions
> when we say that {rsa_pkcs1,dsa,ecdsa}_sha1 are only SHOULD NOT?

Nah.


> I’ll note that we define 256 private use ECDHE group code points but
> only four such FFDHE group code points.  Probably fine, but a bit
> surprising.

Too late now!!


> Should we forbid duplicate entries in
> PreSharedKeyExtension.identities?

I don't think that's necessary.


> Conversely, we might want to explicitly say that duplicate
> OIDFilter.certificate_extension_oid fields should be expected in
> OIDFilterExtensions, to enable the case where multiple values must be
> present.  Or is that supposed to work by concatenating(?) the multiple
> values’ DER encodings in the certificate_extension_values field?

Yeah, I read this text as saying that those all go in the same
DER, not that there can be multiple copies


> I’ll call out for Russ’s attention at the end of Section 4.4.3 where
> we say that “implementations MUST NOT combine external PSKs with
> certificate-based authentication.”  Is there any reason not to qualify
> that as some sort of “don’t’ do it until it’s defined”?

I'm actually going to move and modify this section per your issue #935.


> Should Alert.level be Alert.legacy_level?

i think we went over this and decided not to.


> Appendix B has a claim that “values listed as _RESERVED were used in
> previous versions of TLS and are listed here for completeness”, though
> that is not exactly true, e.g., for ContentType.invalid_RESERVED(0)

I see you fixed this as well.


> Section C.3 notes that “Certificates should always be verified to
> ensure proper signing by a trusted Certificate Authority”, which does
> not use RFC 2119 language, but might be seen as in conflict with
> opportunistic encryption in some circumstances.  I don’t object to
> this text, but it seems worth mentioning.

I think the "Absent a specific..."


> Page 113 still has the “[[NOTE: TLS 1.3 needs a new channel binding
> definition that has not yet been defined.]]”, which should not make it
> into the final spec!

Fixed.


On Mon, Mar 27, 2017 at 11:23 PM, Kaduk, Ben  wrote:

> On 3/13/17, 12:30, "Sean Turner"  wrote:
>
> This is a working group last call announcement for
> draft-ietf-tls-tls13-19, to run through March 27.  Please send your reviews
> to the list as soon as possible so we can prepare for any discussion of
> open issues at IETF 98 in Chicago.
>
> As the price of running the WGLC right during the meeting lead-up, my
> review comes in at the last minute.
>
> Generally, it is in good shape.  I think I still owe some text about what
> we aim for and expect to achieve with respect to side channel resistance,
> though at this point it may be too late to get that text in :(
>
> The following is basically a laundry list of the minor issues; I will send
> editorial notes under separate 

Re: [TLS] WGLC: draft-ietf-tls-tls13-19

[Benjamin Kaduk]

On 03/31/2017 08:40 AM, Hubert Kario wrote:
> On Tuesday, 28 March 2017 08:23:33 CEST Kaduk, Ben wrote:
>> On 3/13/17, 12:30, "Sean Turner"  wrote:
>> Do we want to add some commentary about the extant SHA1 collisions when we
>> say that {rsa_pkcs1,dsa,ecdsa}_sha1 are only SHOULD NOT?
>  
> There still are non-insignificant number of Internet facing servers that 
> require SHA-1 being advertised for connection to be successful.
> SHOULD NOT is a good compromise for it.

Right.  We could note that though SHA1 is "known to be broken", some
servers currently require it, even though they ought to be moving away
from it posthaste.

-Ben
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC: draft-ietf-tls-tls13-19

[Eric Rescorla]

On Fri, Mar 31, 2017 at 9:12 AM, Dr Stephen Henson <
li...@drh-consultancy.co.uk> wrote:

> On 27/03/2017 08:47, Olivier Levillain wrote:
> >
> > For a longer version, post-handshake records of type Handshake can be of
> > three kinds:
> > - NewSessionTicket (sent by the server, and that can safely be ignored
> > entirely by clients)
> > - KeyUpdate (sent by either party, requiring only a bit of state)
> > - CertificateRequest (sent by the server, an arbirary number of times,
> > and requring the client to keep some state *for each request*)
> >
> > Of course, this last item makes the post-handshake client state machine
> > explode, whereas the first two items can ben implemented in a trivial
> > way. The client can not indeed ignore all this state to answer, since it
> > is supposed to answer at least with a Finished message, which will cover
> > the CertificateRequest message. Moreover, since each of these Finished
> > messages must cover the initial handshake and the current
> > CertificateRequest message, it requires a forkable hash implementation,
> > which requires more memory.
> >
>
> To me allowing the server to send multiple certificate request messages
> and the
> client being permitted to respond to them in arbitrary order adds quite a
> bit of
> complexity.
>
> Is there a usage scenario for this? Would permitting only one outstanding
> Certificate Request be too limiting?
>

Yeah, with H2 it puts a lot of complexity at the HTTP layer. I think we
already
had consensus to allow this.



On a related note in 4.6.2:
>
>Note: Because client authentication may require prompting the user,
>servers MUST be prepared for some delay, including receiving an
>arbitrary number of other messages between sending the
>CertificateRequest and receiving a response.
>
> I'm assuming that once the client has responded with a Certificate message
> it
> MUST send CertificateVerify and Finished afterwards and nothing else is
> permissible? That is it can't send application data or respond to other
> outstanding CertificateRequest messages?
>

I think that was our intention but I agree the text ended up a bit unclear.
Absent some
argument, i'll update the text to require it.

-Ekr


>
> Steve.
> --
> Dr Stephen N. Henson.
> Core developer of the   OpenSSL project: http://www.openssl.org/
> Freelance consultant see: http://www.drh-consultancy.co.uk/
> Email: shen...@drh-consultancy.co.uk, PGP key: via homepage.
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC: draft-ietf-tls-tls13-19

[Dr Stephen Henson]

On 27/03/2017 08:47, Olivier Levillain wrote:
> 
> For a longer version, post-handshake records of type Handshake can be of
> three kinds:
> - NewSessionTicket (sent by the server, and that can safely be ignored
> entirely by clients)
> - KeyUpdate (sent by either party, requiring only a bit of state)
> - CertificateRequest (sent by the server, an arbirary number of times,
> and requring the client to keep some state *for each request*)
> 
> Of course, this last item makes the post-handshake client state machine
> explode, whereas the first two items can ben implemented in a trivial
> way. The client can not indeed ignore all this state to answer, since it
> is supposed to answer at least with a Finished message, which will cover
> the CertificateRequest message. Moreover, since each of these Finished
> messages must cover the initial handshake and the current
> CertificateRequest message, it requires a forkable hash implementation,
> which requires more memory.
> 

To me allowing the server to send multiple certificate request messages and the
client being permitted to respond to them in arbitrary order adds quite a bit of
complexity.

Is there a usage scenario for this? Would permitting only one outstanding
Certificate Request be too limiting?

On a related note in 4.6.2:

   Note: Because client authentication may require prompting the user,
   servers MUST be prepared for some delay, including receiving an
   arbitrary number of other messages between sending the
   CertificateRequest and receiving a response.

I'm assuming that once the client has responded with a Certificate message it
MUST send CertificateVerify and Finished afterwards and nothing else is
permissible? That is it can't send application data or respond to other
outstanding CertificateRequest messages?

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shen...@drh-consultancy.co.uk, PGP key: via homepage.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC: draft-ietf-tls-tls13-19

[Hubert Kario]

On Tuesday, 28 March 2017 08:23:33 CEST Kaduk, Ben wrote:
> On 3/13/17, 12:30, "Sean Turner"  wrote:
> Do we want to add some commentary about the extant SHA1 collisions when we
> say that {rsa_pkcs1,dsa,ecdsa}_sha1 are only SHOULD NOT?
 
There still are non-insignificant number of Internet facing servers that 
require SHA-1 being advertised for connection to be successful.
SHOULD NOT is a good compromise for it.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC: draft-ietf-tls-tls13-19

[Eric Rescorla]

Yes, we discussed this at IETF 98 and had rough consensus. I'll be merging
this PR this
week

-Ekr


On Fri, Mar 31, 2017 at 6:57 AM, Olivier Levillain <
olivier.levill...@ssi.gouv.fr> wrote:

> Hi,
>
> > I think there is at least another issue that still needs to be
> > discussed: how to properly handle post-handshake handshake messages.
> >
> > The subject has also been raised several times on GitHub
> > (https://github.com/tlswg/tls13-spec/pull/680,
> > https://github.com/tlswg/tls13-spec/pull/676,
> > https://github.com/tlswg/tls13-spec/issues/572) and on the mailing list
> > (https://www.ietf.org/mail-archive/web/tls/current/msg22038.html).
> >
> > Bottom line is:
> > - handling client late authentication requires a lot of state in the
> > client stack
> > - currently, handling client late authentication is mandatory
>
> [...]
>
> > Thus, I believe the current text is inadequate. Different solutions are
> > possible :
> > - remove client late authentication entirely (this would have my
> > preference, since it introduces other issues*)
> > - make client late authentication optional (compatible clients would
> > signal it as an extension)
> > - rethink the client late authentication, as was done with KeyUpdate,
> > to limit the state required on the client side.
>
>
> Martin Thomson proposed a PR (thank you) corresponding to the second
> point, using a simple extension in the ClientHello :
> https://github.com/tlswg/tls13-spec/pull/921/
>
> I believe this proposal is a good trade-off allowing simpler
> implementation designs when late client authentication is not needed.
>
>
> Best regards,
> Olivier Levillain
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC: draft-ietf-tls-tls13-19

[Olivier Levillain]

Hi,

> I think there is at least another issue that still needs to be
> discussed: how to properly handle post-handshake handshake messages.
> 
> The subject has also been raised several times on GitHub
> (https://github.com/tlswg/tls13-spec/pull/680,
> https://github.com/tlswg/tls13-spec/pull/676,
> https://github.com/tlswg/tls13-spec/issues/572) and on the mailing list
> (https://www.ietf.org/mail-archive/web/tls/current/msg22038.html).
> 
> Bottom line is:
> - handling client late authentication requires a lot of state in the
> client stack
> - currently, handling client late authentication is mandatory

[...]

> Thus, I believe the current text is inadequate. Different solutions are
> possible :
> - remove client late authentication entirely (this would have my
> preference, since it introduces other issues*)
> - make client late authentication optional (compatible clients would
> signal it as an extension)
> - rethink the client late authentication, as was done with KeyUpdate,
> to limit the state required on the client side.


Martin Thomson proposed a PR (thank you) corresponding to the second
point, using a simple extension in the ClientHello :
https://github.com/tlswg/tls13-spec/pull/921/

I believe this proposal is a good trade-off allowing simpler
implementation designs when late client authentication is not needed.


Best regards,
Olivier Levillain

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC: draft-ietf-tls-tls13-19

[Kyle Nekritz]

I raised this before in PR #693 
(https://www.ietf.org/mail-archive/web/tls/current/msg21600.html).

I'm not sure it makes sense to rename this to legacy while other parts of the 
document still refer to it. But I'm definitely in favor of deprecating it.

From: TLS <tls-boun...@ietf.org> on behalf of Dave Garrett 
<davemgarr...@gmail.com>
Sent: Tuesday, March 28, 2017 4:42 PM
To: tls@ietf.org
Subject: Re: [TLS] WGLC: draft-ietf-tls-tls13-19
    
On Tuesday, March 28, 2017 02:23:33 am Kaduk, Ben wrote:
> Should Alert.level be Alert.legacy_level?

Yep. Trivial to fix, so quick PR filed for it.


Dave

___
TLS mailing list
TLS@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls=DwICAg=5VD0RTtNlTh3ycd41b3MUw=l2j4BjkO0Lc3u4CH2z7jPw=ix39YzN5D9ZIP69oc6EpeIHky4mBDPr78L-0dRI3acY=wDljuAs_X9UuW_4VC-TwYR9TkDPrKiVZz7oRdOmL3aA=

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC: draft-ietf-tls-tls13-19

[Dave Garrett]

On Tuesday, March 28, 2017 02:23:33 am Kaduk, Ben wrote:
> Should Alert.level be Alert.legacy_level?

Yep. Trivial to fix, so quick PR filed for it.


Dave

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC: draft-ietf-tls-tls13-19

[Kaduk, Ben]

On 3/13/17, 12:30, "Sean Turner"  wrote:

This is a working group last call announcement for draft-ietf-tls-tls13-19, 
to run through March 27.  Please send your reviews to the list as soon as 
possible so we can prepare for any discussion of open issues at IETF 98 in 
Chicago.  

As the price of running the WGLC right during the meeting lead-up, my review 
comes in at the last minute.

Generally, it is in good shape.  I think I still owe some text about what we 
aim for and expect to achieve with respect to side channel resistance, though 
at this point it may be too late to get that text in :(

The following is basically a laundry list of the minor issues; I will send 
editorial notes under separate cover, probably as a pull request.

It was already mentioned that the “major differences from TLS 1.2” section 
should not be a changelog, but I agree with that.

Should Figure 4 (“message flow for a zero round trip handshake”) include a “+ 
early_data” for the server’s flight?  (The legend for Figure 4 also lacks the 
explanation for the ‘+’ symbol.)

The language on page 30 is perhaps unclear:

   Because TLS 1.3 forbids renegotiation, if a server receives a
   ClientHello at any other time, it MUST terminate the connection.

Is that any TLS server, or just one that has negotiated and is using TLS 1.3?

In the description of legacy_compression_methods on page 31, we make 
restrictions on “every TLS 1.3 ClientHello”, but do not say how such things are 
identified.  (Hmm, maybe we also do so elsewhere in the document, too, now that 
I search for where)  we explicitly define what a client “considered to be 
attempting to negotiate using this specification (i.e., a TLS 1.3 ClientHEello) 
on page 87, as supported_versions including 1.3.  Which, is maybe not the most 
future-proof thing.

The description of version negotiation (to populate ServerHello.version) on 
page 32 seems to leave undefined what the server should do when receiving a 
ClientHello that does not contain a supported_versions extension.  (Also, I 
don’t think “ClientHello.supported_versions extension” is a well-defined 
syntax.)

When covering the server_random version downgrade sentinels, we do not mention 
what is to be done when downgrading to TLS 1.0, which I thought was still a 
permitted version by this spec.

It’s a little odd that we list in enum ExtensionType on page 35 a strict subset 
of the extensions enumerated in the table on the following pages.

Do we want to add some commentary about the extant SHA1 collisions when we say 
that {rsa_pkcs1,dsa,ecdsa}_sha1 are only SHOULD NOT?

I’ll note that we define 256 private use ECDHE group code points but only four 
such FFDHE group code points.  Probably fine, but a bit surprising.

Should we forbid duplicate entries in PreSharedKeyExtension.identities?

Conversely, we might want to explicitly say that duplicate 
OIDFilter.certificate_extension_oid fields should be expected in 
OIDFilterExtensions, to enable the case where multiple values must be present.  
Or is that supposed to work by concatenating(?) the multiple values’ DER 
encodings in the certificate_extension_values field?

I’ll call out for Russ’s attention at the end of Section 4.4.3 where we say 
that “implementations MUST NOT combine external PSKs with certificate-based 
authentication.”  Is there any reason not to qualify that as some sort of 
“don’t’ do it until it’s defined”?

Should Alert.level be Alert.legacy_level?

The editors copy has already removed the reference to RFC 4507, which is 
obsoleted by RFC 5077 (and was not cited anywhere, anyway).

Appendix B has a claim that “values listed as _RESERVED were used in previous 
versions of TLS and are listed here for completeness”, though that is not 
exactly true, e.g., for ContentType.invalid_RESERVED(0)

Section C.3 notes that “Certificates should always be verified to ensure proper 
signing by a trusted Certificate Authority”, which does not use RFC 2119 
language, but might be seen as in conflict with opportunistic encryption in 
some circumstances.  I don’t object to this text, but it seems worth mentioning.

Page 113 still has the “[[NOTE: TLS 1.3 needs a new channel binding definition 
that has not yet been defined.]]”, which should not make it into the final spec!

-Ben

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC: draft-ietf-tls-tls13-19

[Olivier Levillain]

Hi list,

I think there is at least another issue that still needs to be
discussed: how to properly handle post-handshake handshake messages.

The subject has also been raised several times on GitHub
(https://github.com/tlswg/tls13-spec/pull/680,
https://github.com/tlswg/tls13-spec/pull/676,
https://github.com/tlswg/tls13-spec/issues/572) and on the mailing list
(https://www.ietf.org/mail-archive/web/tls/current/msg22038.html).

Bottom line is:
- handling client late authentication requires a lot of state in the
client stack
- currently, handling client late authentication is mandatory


For a longer version, post-handshake records of type Handshake can be of
three kinds:
- NewSessionTicket (sent by the server, and that can safely be ignored
entirely by clients)
- KeyUpdate (sent by either party, requiring only a bit of state)
- CertificateRequest (sent by the server, an arbirary number of times,
and requring the client to keep some state *for each request*)

Of course, this last item makes the post-handshake client state machine
explode, whereas the first two items can ben implemented in a trivial
way. The client can not indeed ignore all this state to answer, since it
is supposed to answer at least with a Finished message, which will cover
the CertificateRequest message. Moreover, since each of these Finished
messages must cover the initial handshake and the current
CertificateRequest message, it requires a forkable hash implementation,
which requires more memory.

A client _could_ ignore CertificateRequest and never answer them, but
this would not really be conformant, and it would be problematic as soon
as the parties need to send Handshake messages.


Thus, I believe the current text is inadequate. Different solutions are
possible :
- remove client late authentication entirely (this would have my
preference, since it introduces other issues*)
- make client late authentication optional (compatible clients would
signal it as an extension)
- rethink the client late authentication, as was done with KeyUpdate,
to limit the state required on the client side.

Best regards,
Olivier Levillain


* One of these issues is that requiring Client Authentication upon an
applicative request may lead a client to have to write records on a
SSL_read call :
1) client and server complete the handshake
2) client sends a request (SSL_write)
3) server reads the request, decides an authentication is required, and
sends a CR
4) client reads the response (SSL_read), but has first to comply with
the CR (that is write packets) to get the response

This violation of the network layers can be dealt with (and has been,
since Apache allows eactly this kind of flow) but it introduces
complexity in the code, which I belive we should remove altogether : an
application request should not trigger an SSL authentication request.
What was done with KeyUpdate sanitized a similar situation.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC: draft-ietf-tls-tls13-19

[Dave Garrett]

Yes, a proper "differences from TLS 1.2" section needs to be written to replace 
the draft changelog.


Dave


On Tuesday, March 14, 2017 05:31:18 am Yoav Nir wrote:
> Hi.
> 
> I will give the entire document a more thorough read, but I wanted to comment 
> on section 1.2 earlier. Its title is “Major differences from TLS 1.2”, but 
> the content is a change-log. The kind of change-log that usually gets deleted 
> by the RFC editor.
> 
> I hope we don’t plan to publish with sentences like “Allow cookies to be 
> longer”.  OTOH I think it will be useful to have an actual “major differences 
> from TLS 1.2” section, but AFAICT it’s not yet written.
> 
> Yoav
> 
> > On 13 Mar 2017, at 19:30, Sean Turner  wrote:
> > 
> > This is a working group last call announcement for draft-ietf-tls-tls13-19, 
> > to run through March 27.  Please send your reviews to the list as soon as 
> > possible so we can prepare for any discussion of open issues at IETF 98 in 
> > Chicago.
> > 
> > Thanks,
> > J
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC: draft-ietf-tls-tls13-19

[Eric Rescorla]

Note to Ilari: I have already taken your email as WGLC comments, so no need
to
re-send.

-Ekr


On Mon, Mar 13, 2017 at 10:30 AM, Sean Turner  wrote:

> This is a working group last call announcement for
> draft-ietf-tls-tls13-19, to run through March 27.  Please send your reviews
> to the list as soon as possible so we can prepare for any discussion of
> open issues at IETF 98 in Chicago.
>
> Thanks,
> J
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls