[TLS] IETF-98 Minutes

[Joseph Salowey]

Draft meeting minutes are now available in the draft proceedings:
https://www.ietf.org/proceedings/98/minutes/minutes-98-tls-00.txt

Let me know if you have an additions/corrections.

Thanks,

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

Re: [TLS] comments on draft-ietf-tls-tls13-19

[Eric Rescorla]

On Tue, Apr 11, 2017 at 2:25 PM, Ilari Liusvaara 
wrote:

> On Tue, Apr 11, 2017 at 01:47:08PM -0700, Eric Rescorla wrote:
> > Thanks for your comments.
> >
> > > 4.1.2. It is not defined what a server should do if encountered with a
> > > ProtocolVersion of TLS 1.3.
> >
> > https://tlswg.github.io/tls13-spec/#supported-versions says:
> >
> >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. Servers MAY abort the handshake upon receiving a ClientHello
> >with legacy_version 0x0304 or later.
>
> I think that MAY abort should be removed. client_version field has
> always been defined to be tolerant to higher values.
>

It seems like we are ossifyng that extension point. Otherwise it's very
hard to interpret. But I'm willing to defer if the WG objects.


> > However, as David Benjamin points out, it's not clear how one would
> > handle this in practice, because HRR is an instruction to the client
> > to do something, so if it can't parse that then the handshake fails.
>
> I think if one wanted to have new mandatory HRR extension, one could
> just have it sent, resulting older clients blowing up. But those would
> not be able to connect anyway.
>

That's what we have now :)



> > > 4.3.2.1. The OID Filters extension on a first look seems quite
> > > independent and unrelated to everything else in this document (seemed
> > > quite a distraction that could have been in an appendix as well).
> >
> > This is a fair point, but it's been in the document a long time,
> > so I think this would require WG Consensus.
>
> Also, I have no idea of exact contents of that extension (maybe some mail
> to this list has those, but that won't do with RFCs), as I can interpret
> the thing in multiple ways.


Hmm.. I did think the text was reasonably clear, but maybe I am in too deep.



> > > 4.4.2.2., 4.4.2.3.
> > > I think the reference to RFC5081 should be replaced with RFC5270 which
> > > obsoletes the former even though not explicitly.
> >
> > Indeed. Also, we are now explicitly prohibiting OpenPGP per discussion
> > in Chicago.
>
> Also, maybe needs some text about possible future Certificate Types
> (or are those akin to DNS classes: heavy objects dropped by bad idea
> fairy? :-) ).
>
> Also, client_certificate_type looks to be still CH,EE, which is not
> good if any future certificate types might get defined (or even if
> just RPK is allowed).
>

Actually, I think this is still right. The reason is that this extension
applies
to the client's entire certificate message, not to each certificate, so it
needs to be negotiated up front.

-Ekr



> > > B.4.
> > > I believe it was discussed before, but I miss the AES-256-CCM
> > > ciphersuites. If only one must be defined, it may be better to only
> > > have the 256-bit variants (at least for the non-mac-truncated version)
> >
> > Open to WG feedback here as well.
>
> Also, who uses those? It seems like CCM is mostly for things, and those
> don't use AES-256, as AES-128 already seems quite much for various IoS.
>
> Also, if one wanted special ciphersuite for things, I think there are
> ones that are implementable in smaller space than AES CCM.
>
>
> -Ilari
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] comments on draft-ietf-tls-tls13-19

[Ilari Liusvaara]

On Tue, Apr 11, 2017 at 01:47:08PM -0700, Eric Rescorla wrote:
> Thanks for your comments.
> 
> > 4.1.2. It is not defined what a server should do if encountered with a
> > ProtocolVersion of TLS 1.3.
> 
> https://tlswg.github.io/tls13-spec/#supported-versions says:
> 
>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. Servers MAY abort the handshake upon receiving a ClientHello
>with legacy_version 0x0304 or later.

I think that MAY abort should be removed. client_version field has
always been defined to be tolerant to higher values.
 
> However, as David Benjamin points out, it's not clear how one would
> handle this in practice, because HRR is an instruction to the client
> to do something, so if it can't parse that then the handshake fails.

I think if one wanted to have new mandatory HRR extension, one could
just have it sent, resulting older clients blowing up. But those would
not be able to connect anyway.
 
> > 4.2.7. There is no guidance on the use of max_early_data_size.
> > I'd find it natural to have a recommended minimum value for application
> > protocols layered on TLS to take into account. E.g., text like servers
> > supporting early_data SHOULD allow at least 1024 bytes of data
> > (arbitrary number). Is the 32-bit upper limit intentional?
> 
> I think it's just a result of the way the PDU is formatted. I
> would be interested in seeing a PR with guidance...

The max_early_data_size looks kinda iffy. I understand the justification
is about buffering for verification, but that kind of buffering AFAICT
destroys the benefits of 0-RTT, so I would just skip 0-RTT if I knew
such buffering would take place.
 
> > The text recommends: "a server SHOULD measure the round trip time prior
> > to sending the NewSessionTicket message". I see two issues here. (1) it
> > doesn't mention how to do this measurement --my guess is that this can
> > be done in the context of TLS--, and (2) it assumes that round-trips
> > are fixed over time. About (1), I ask because the obvious measurement
> > time between [server Application Data*] and client [Certificate*] would
> > include the processing of the application data by the client.
> > On (2), this check will not work as is for mobile clients which will
> > have variable round-trips.

The thresholds seem so loose anyway, that I don't see much need to even
try to measure the RTT, one can seemingly just ignore them.

> > 4.3.2.1. The OID Filters extension on a first look seems quite
> > independent and unrelated to everything else in this document (seemed
> > quite a distraction that could have been in an appendix as well).
> 
> This is a fair point, but it's been in the document a long time,
> so I think this would require WG Consensus.

Also, I have no idea of exact contents of that extension (maybe some mail
to this list has those, but that won't do with RFCs), as I can interpret
the thing in multiple ways. 
 
> > 4.4.2.1.  OCSP Status and SCT Extensions
> > This is a very nice addition to TLS 1.3. Something that I miss as an
> > implementer is guidelines on how to determine the (time) validity of an
> > OCSP stapled response. Here my point is that OCSP responses have
> > several fields optional (e.g., nextUpdate), which make a validation to
> > be hand-wavy. It would be nice to have a profile of OCSP responses that
> > would be recommended for use in TLS, as well or a recommendation of
> > what constitutes a "fresh" response for use in TLS.
> 
> Do you have any thoughts on what text we should insert here? I admit
> to being not that familiar with the practical matters of OCSP stapling.

Well, my implementation considers OCSP responses valid to NextUpdate,
and fails handshake if it is absent but OCSP staple is sent.

> > 4.4.2.2., 4.4.2.3.
> > I think the reference to RFC5081 should be replaced with RFC5270 which
> > obsoletes the former even though not explicitly.
> 
> Indeed. Also, we are now explicitly prohibiting OpenPGP per discussion
> in Chicago.

Also, maybe needs some text about possible future Certificate Types
(or are those akin to DNS classes: heavy objects dropped by bad idea
fairy? :-) ). 

Also, client_certificate_type looks to be still CH,EE, which is not
good if any future certificate types might get defined (or even if
just RPK is allowed).
 
> > 4.4.3. "RSA signatures MUST use an RSASSA-PSS algorithm". What should a
> > client or server do when encounters an non RSA-PSS signature in TLS

Well, my implementation just aborts. I have actually seen an TLS 1.3
draft implementation sign with RSA PKCS#1 (it did so if one sent a
ClientHello that only had that and ECDSA and EdDSAs).

> > 4.6.3. My comment on this section, is that leaving up to the
> > implementer to decide the re-key, would most probably result in the
> > implementer delegating that decision to the application. In 

Re: [TLS] comments on draft-ietf-tls-tls13-19

[Eric Rescorla]

Thanks for your comments.


> 1.2. Major Differences from TLS 1.2
>  It is very hard to make use of this section as is. It is organized on
> per-draft, while it would be expected to have the changes of the
> document since TLS 1.2. It contains phrases like "Remove spurious
> requirement to implement "pre_shared_key"." At its current state it is
> not useful to someone familiar with TLS 1.2.

Yes, I agree. This is an action item for me.



> 2. Figure 1 ascii art is a bit awkward (IMHO). "Key Exch" looks like
> bad shortening. Symbols '^' and 'v' were confusing on the first read.
> A suggestion could be to avoid ^v, and define shortened terminology
> upfront and use it on the figures.
>
> One the content, Figure 1 contents are too many to swallow at an
> overview. A suggestion would be to split into two diagrams (preshared
> keys and not).

I agree that this is a bit hard to take in, but I'd like to have
a unified diagram. I'll see what I can do about the shortening.


> A more general note on the section/document, is that although the PKIX
> identity (certificate) is protected from passive adversaries, the PSK
> identity is not. This is a discrepancy in terms of protecting the
> user's identity between PSK and certificate authentication (that should
> warrant .

I agree. I will mention this.


> 4.1.1. HelloRetryRequest how many times can it be re-sent by the
> server? I assume only a single one, but it maybe good to make it
> explicit.

This is forbidden in S 4.1.4.
https://tlswg.github.io/tls13-spec/#hello-retry-request

   If a client receives a second HelloRetryRequest in the same
   connection (i.e., where the ClientHello was itself in response to a
   HelloRetryRequest), it MUST abort the handshake with an
   “unexpected_message” alert.

Does this seem sufficient?





> 4.1.2. It is not defined what a server should do if encountered with a
> ProtocolVersion of TLS 1.3.

https://tlswg.github.io/tls13-spec/#supported-versions says:

   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. Servers MAY abort the handshake upon receiving a ClientHello
   with legacy_version 0x0304 or later.





> 4.2. rfc6961 is standard's track but TLS 1.3 only uses the RFC6066
> status request. Why not require RFC6961?

Because TLS 1.3 allows you to attach OSCP-stapled responses to each
certificate with status_request, we felt that 6961 was superseded.


> 4.2. the exception for including cookie in HelloRetryRequest seems like
> something that could cause issues in future revisions. Any future
> revision of the protocol would not be able to add such exceptions
> (since they will be rejected by existing clients), and the fact that
> the cookie is there, it indicates that such an exception may be useful.
> A suggestion to address that would be to allow the HelloRetryRequest
> contain any extension or grant an exception to a specific extension
> number range.

Yes, this is an interesting suggestion. I have filed issue:

https://github.com/tlswg/tls13-spec/issues/939

However, as David Benjamin points out, it's not clear how one would
handle this in practice, because HRR is an instruction to the client
to do something, so if it can't parse that then the handshake fails.


> 4.2.5.2. The parameters are informally defined.
> I'd suggest to follow rfc4492bis and use its text as in:
>  https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-16#section-5.4.1

Good idea.
https://github.com/tlswg/tls13-spec/issues/943


> 4.2.7. There is no guidance on the use of max_early_data_size.
> I'd find it natural to have a recommended minimum value for application
> protocols layered on TLS to take into account. E.g., text like servers
> supporting early_data SHOULD allow at least 1024 bytes of data
> (arbitrary number). Is the 32-bit upper limit intentional?

I think it's just a result of the way the PDU is formatted. I
would be interested in seeing a PR with guidance...


> 4.2.8. This section changes the semantics for pre-shared keys as used
> in any other protocol (including TLS 1.2). With the new text it
> implies, pre-shared keys must be combined with a hash algorithm. Thus
> existing PSK deployments which share keys and would like to upgrade to
> TLS 1.3 cannot do transparently. They would have to fix to a specific
> hash algorithm for their existing PSKs, and make sure they provide that
> information to all the underlying software (which may be different on
> the server and client side). I could find no implementation guideline
> on what to do in the case of pre-existing PSKs in that text.
>
> My recommendation would be to switch the sentence "For externally
> established PSKs, the Hash algorithm MUST be set when the PSK is
> established" to "For externally established PSKs, the Hash algorithm
> MUST be set when the PSK is established, or default to SHA-256". That
> way 

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] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead

[Daniel Migault]

Hi Joe,

Thanks for the reminder. I just posted it. Let me know if there is anything
I have to do.

Yours,
Daniel

On Tue, Apr 11, 2017 at 11:21 AM, Joseph Salowey  wrote:

> Hi Daniel,
>
> Please submit a revised draft with the changes below.
>
> Thanks,
>
> Joe
>
>
> On Tue, Mar 21, 2017 at 11:08 AM, Daniel Migault <
> daniel.miga...@ericsson.com> wrote:
>
>> Hi,
>>
>> Thank you for the review and comments received. Given the discussion our
>> understanding was that the consensus was to remove CCM-256 so that suites
>> defined by the document apply both for TLS1.2 as well as for TLS1.3. The
>> draft available on github [1
>> ]
>> has been updated as follows:
>>
>>
>> 1.  Why does TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 use SHA256 instead
>> of SHA384 like the other 256 bit cipher suites? (From Russ Housley)
>>
>> MGLT: This was a mistake in the IANA section. The cypher suite was
>> correct in the remaining text. However, the current version does not
>> consider anymore CCM-256* which also solves this issue.
>>
>> 2.  Since the security considerations mention passwords (human chosen
>> secrets) it should mention dictionary attacks. (From Russ Housley)
>>
>> MGLT: The issue of human chosen passwords and dictionary attacks has been
>> mentioned in the security consideration with the following text:
>>
>> """
>>Use of Pre-Shared Keys of limited entropy may allow an active
>>attacker attempts to connect to the server and tries different keys.
>>For example, limited entropy may be provided by using short PSK in
>>which case an attacker may perform a brute-force attack.  Other
>>example includes the use of a PSK chosen by a human and thus may be
>>exposed to dictionary attacks.
>> """
>>
>>
>> 3.  Section 2 and 3 of the document contains more detail about TLS 1.3
>> than necessary.
>>
>> Section 2: This document only defines cipher suites for TLS 1.2, not TLS
>> 1.2 or later.  A subset of equivalent cipher suites is defined in the TLS
>> 1.3 specification.
>>
>> MGLT: CCM-256 has been removed from the specification so that suites can
>> be defined for TLS 1.2 as well as TLS1.3. The following text is considered.
>>
>> """
>>This document defines new cipher suites that provide Pre-Shared Key
>>(PSK) authentication, Perfect Forward Secrecy (PFS), and
>>Authenticated Encryption with Associated Data (AEAD).  The cipher
>>suites are defined for version 1.2 of the Transport Layer Security
>>(TLS) [RFC5246] protocol, version 1.2 of the Datagram Transport Layer
>>Security (DTLS) protocol [RFC6347], as well as version 1.3 of TLS
>>[I-D.ietf-tls-tls13].
>> """
>>
>> Section 3 and 4: Maybe replace the last 2 paragraphs with an addition to
>> section 4 that states:
>>
>> "TLS 1.3 and above name, negotiate and support a subset of these cipher
>> suites in a different way."  (TLS 1.3 does not support
>> TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 and TLS_ECDHE_PSK_WITH_AES_256_CCM
>> _8_SHA256)
>>
>> MGLT: As CCM-256 has been removed, we do not have to deal with the
>> situation where TLS1.3 only considers a subset of the suites defined for
>> TLS1.2.
>>
>> The following sentence in section 3 clarifies that codes points are only
>> defined for TLS1.2: “””The assigned code points can only be used for TLS
>> 1.2.”””. The description of the TLS1.3 negotiation has been limited in
>> section 4 to the following sentence: “””TLS 1.3 and above version,
>> negotiate and support these cipher suites in a different way.”””
>>
>> 4. Section 3 should contain a bit more detail about relationship to 4492
>> bis and RFC 4279:
>>
>> Something like the following may be enough.
>>
>> "This messages and pre-master secret construction in this document are
>> based on [RFC4279].  The elliptic curve parameters used in in the
>> Diffie-Hellman parameters are negotiated using extensions defined in
>> [4492-bis]."
>>
>> MGLT: The sentence mentioned above has been added with [4492-bis]
>> mentioned as normative.
>> “””
>> Messages and pre-master secret construction in this document are
>>based on [RFC4279].  The elliptic curve parameters used in in the
>>Diffie-Hellman parameters are negotiated using extensions defined in
>>[I-D.ietf-tls-rfc4492bis].
>> “””
>>
>> [1] https://github.com/mglt/draft-ietf-tls-ecdhe-psk-aead/blob/m
>> aster/draft-ietf-tls-ecdhe-psk-aead
>>
>> Yours,
>> Daniel and John
>>
>>
>> On Tue, Feb 21, 2017 at 1:22 PM, Joseph Salowey  wrote:
>>
>>> Here are the open issues for draft-ietf-tls-ecdhe-psk-aead
>>>
>>> 1.  Why does TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 use SHA256 instead
>>> of SHA384 like the other 256 bit cipher suites? (From Russ Housley)
>>>
>>> 2.  Since the security considerations mention passwords (human chosen
>>> secrets) it should mention dictionary attacks. (From Russ Housley)
>>>
>>> 3.  Section 2 and 3 of the 

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 

[TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-02.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security of the IETF.

Title   : ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for 
Transport Layer Security (TLS)
Authors : John Mattsson
  Daniel Migault
Filename: draft-ietf-tls-ecdhe-psk-aead-02.txt
Pages   : 7
Date: 2017-04-11

Abstract:
   This document defines several new cipher suites for the Transport
   Layer Security (TLS) protocol.  The cipher suites are all based on
   the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key
   (ECDHE_PSK) key exchange together with the Authenticated Encryption
   with Associated Data (AEAD) algorithms AES-GCM and AES-CCM.  PSK
   provides light and efficient authentication, ECDHE provides perfect
   forward secrecy, and AES-GCM and AES-CCM provides encryption and
   integrity protection.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-ecdhe-psk-aead-02
https://datatracker.ietf.org/doc/html/draft-ietf-tls-ecdhe-psk-aead-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-ecdhe-psk-aead-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead

[Joseph Salowey]

Hi Daniel,

Please submit a revised draft with the changes below.

Thanks,

Joe

On Tue, Mar 21, 2017 at 11:08 AM, Daniel Migault <
daniel.miga...@ericsson.com> wrote:

> Hi,
>
> Thank you for the review and comments received. Given the discussion our
> understanding was that the consensus was to remove CCM-256 so that suites
> defined by the document apply both for TLS1.2 as well as for TLS1.3. The
> draft available on github [1
> ]
> has been updated as follows:
>
>
> 1.  Why does TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 use SHA256 instead
> of SHA384 like the other 256 bit cipher suites? (From Russ Housley)
>
> MGLT: This was a mistake in the IANA section. The cypher suite was correct
> in the remaining text. However, the current version does not  consider
> anymore CCM-256* which also solves this issue.
>
> 2.  Since the security considerations mention passwords (human chosen
> secrets) it should mention dictionary attacks. (From Russ Housley)
>
> MGLT: The issue of human chosen passwords and dictionary attacks has been
> mentioned in the security consideration with the following text:
>
> """
>Use of Pre-Shared Keys of limited entropy may allow an active
>attacker attempts to connect to the server and tries different keys.
>For example, limited entropy may be provided by using short PSK in
>which case an attacker may perform a brute-force attack.  Other
>example includes the use of a PSK chosen by a human and thus may be
>exposed to dictionary attacks.
> """
>
>
> 3.  Section 2 and 3 of the document contains more detail about TLS 1.3
> than necessary.
>
> Section 2: This document only defines cipher suites for TLS 1.2, not TLS
> 1.2 or later.  A subset of equivalent cipher suites is defined in the TLS
> 1.3 specification.
>
> MGLT: CCM-256 has been removed from the specification so that suites can
> be defined for TLS 1.2 as well as TLS1.3. The following text is considered.
>
> """
>This document defines new cipher suites that provide Pre-Shared Key
>(PSK) authentication, Perfect Forward Secrecy (PFS), and
>Authenticated Encryption with Associated Data (AEAD).  The cipher
>suites are defined for version 1.2 of the Transport Layer Security
>(TLS) [RFC5246] protocol, version 1.2 of the Datagram Transport Layer
>Security (DTLS) protocol [RFC6347], as well as version 1.3 of TLS
>[I-D.ietf-tls-tls13].
> """
>
> Section 3 and 4: Maybe replace the last 2 paragraphs with an addition to
> section 4 that states:
>
> "TLS 1.3 and above name, negotiate and support a subset of these cipher
> suites in a different way."  (TLS 1.3 does not support
> TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 and TLS_ECDHE_PSK_WITH_AES_256_
> CCM_8_SHA256)
>
> MGLT: As CCM-256 has been removed, we do not have to deal with the
> situation where TLS1.3 only considers a subset of the suites defined for
> TLS1.2.
>
> The following sentence in section 3 clarifies that codes points are only
> defined for TLS1.2: “””The assigned code points can only be used for TLS
> 1.2.”””. The description of the TLS1.3 negotiation has been limited in
> section 4 to the following sentence: “””TLS 1.3 and above version,
> negotiate and support these cipher suites in a different way.”””
>
> 4. Section 3 should contain a bit more detail about relationship to 4492
> bis and RFC 4279:
>
> Something like the following may be enough.
>
> "This messages and pre-master secret construction in this document are
> based on [RFC4279].  The elliptic curve parameters used in in the
> Diffie-Hellman parameters are negotiated using extensions defined in
> [4492-bis]."
>
> MGLT: The sentence mentioned above has been added with [4492-bis]
> mentioned as normative.
> “””
> Messages and pre-master secret construction in this document are
>based on [RFC4279].  The elliptic curve parameters used in in the
>Diffie-Hellman parameters are negotiated using extensions defined in
>[I-D.ietf-tls-rfc4492bis].
> “””
>
> [1] https://github.com/mglt/draft-ietf-tls-ecdhe-psk-aead/blob/
> master/draft-ietf-tls-ecdhe-psk-aead
>
> Yours,
> Daniel and John
>
>
> On Tue, Feb 21, 2017 at 1:22 PM, Joseph Salowey  wrote:
>
>> Here are the open issues for draft-ietf-tls-ecdhe-psk-aead
>>
>> 1.  Why does TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 use SHA256 instead
>> of SHA384 like the other 256 bit cipher suites? (From Russ Housley)
>>
>> 2.  Since the security considerations mention passwords (human chosen
>> secrets) it should mention dictionary attacks. (From Russ Housley)
>>
>> 3.  Section 2 and 3 of the document contains more detail about TLS 1.3
>> than necessary.
>>
>> Section 2: This document only defines cipher suites for TLS 1.2, not TLS
>> 1.2 or later.  A subset of equivalent cipher suites is defined in the TLS
>> 1.3 specification.
>>
>> Section 3 and 4: Maybe replace the last 2 paragraphs with an addition to
>>