Re: [TLS] Harmonizing 4492bis with TLS 1.3

2016-12-13 Thread Martin Thomson 
On 14 December 2016 at 16:42, Yoav Nir  wrote:
> Aren’t we going to have separate registries for 1.2 and 1.3?  We don’t want 
> to force anyone to make the changes you had made (as part of 1.3) just to get 
> EdDSA..And I need to request things from IANA based on 1.2 registries.

Yes, but I was thinking that there might be an expectation about 1.2
values and the way they propagate into the 1.3 registry.  We don't
want that here.

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

Re: [TLS] Harmonizing 4492bis with TLS 1.3

2016-12-13 Thread Yoav Nir 

> On 14 Dec 2016, at 3:33, Martin Thomson  wrote:
> 
> On 13 December 2016 at 22:47, Yoav Nir  wrote:
>> 2. Change 4492bis:
>> a. no new curves for ed25519 and ed448.
>> b. Two new signature algorithms, and request values 7 and 8 for them.
>> c. new hash algorithm 0x08 and call it something like “intrinsic”
> 
> This, but with a small tweak: don't treat these values as requiring
> special reservation (as we have done for existing hash/signature
> values).
> 
> Rather than blocking out all 0x08 hashes, which might be the
> consequence of this change, we can say that a hash of 0x08 AND either
> 0x07 or 0x08 identify these signature schemes.  We need to be able to
> allocate 0x0809 at some point later.

Aren’t we going to have separate registries for 1.2 and 1.3?  We don’t want to 
force anyone to make the changes you had made (as part of 1.3) just to get 
EdDSA..And I need to request things from IANA based on 1.2 registries.

> Maybe also include a reference to TLS 1.3 (informative only) and
> mention that this is compatible with the change from SignatureAndHash
> to SignatureScheme in TLS 1.3.

Already got a reference to 1.3. Might as well add this.

> Like Ilari, I have backported the TLS 1.3 change to TLS 1.2 and it
> works fine.  It actually fixed some old bugs (such being unable to
> sign with P-521 and SHA-256, but trying anyway).

The hashed input to P-521 is treated as a number. Why doesn’t it work if the 
number is smaller? Note that even SHA-512 is 9 bits “too small”.  It’s the 
other way around that is challenging. But even that is well-defined.

Yoav

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

Re: [TLS] Harmonizing 4492bis with TLS 1.3

2016-12-13 Thread Martin Thomson 
On 13 December 2016 at 22:47, Yoav Nir  wrote:
> 2. Change 4492bis:
>  a. no new curves for ed25519 and ed448.
>  b. Two new signature algorithms, and request values 7 and 8 for them.
>  c. new hash algorithm 0x08 and call it something like “intrinsic”

This, but with a small tweak: don't treat these values as requiring
special reservation (as we have done for existing hash/signature
values).

Rather than blocking out all 0x08 hashes, which might be the
consequence of this change, we can say that a hash of 0x08 AND either
0x07 or 0x08 identify these signature schemes.  We need to be able to
allocate 0x0809 at some point later.

Maybe also include a reference to TLS 1.3 (informative only) and
mention that this is compatible with the change from SignatureAndHash
to SignatureScheme in TLS 1.3.

Like Ilari, I have backported the TLS 1.3 change to TLS 1.2 and it
works fine.  It actually fixed some old bugs (such being unable to
sign with P-521 and SHA-256, but trying anyway).

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

Re: [TLS] Confirming consensus: TLS1.3->TLS*

2016-12-13 Thread Joseph Salowey 
Thanks to all those that participated in the list discussion, it was a very
popular topic.  On the list and in the meeting, TLS 1.3 had more support
than any other option so we believe there is rough consensus to leave the
name of the protocol as TLS 1.3.

Thanks,

J&S

On Sat, Dec 3, 2016 at 10:15 PM, Mohan Sekar 
wrote:

> +1 on Tony comment
>
>
>
> - Keep this version TLS 1.3
>
> - For the next version of TLS, drop the 1.x and call it TLS 4
>
>
>
> Mohan Sekar
>
>
>
> *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Tony Arcieri
> *Sent:* Saturday, December 3, 2016 9:04 AM
> *To:* Sean Turner 
> *Cc:*  
> *Subject:* Re: [TLS] Confirming consensus: TLS1.3->TLS*
>
>
>
> On Thu, Nov 17, 2016 at 6:12 PM, Sean Turner  wrote:
>
> The consensus in the room was to leave it as is, i.e., TLS1.3, and to not
> rebrand it to TLS 2.0, TLS 2, or TLS 4.  We need to confirm this decision
> on the list so please let the list know your top choice between:
>
> - Leave it TLS 1.3
> - Rebrand TLS 2.0
> - Rebrand TLS 2
> - Rebrand TLS 4
>
> by 2 December 2016.
>
>
>
> I guess we're at the deadline, but I have a compromise I think makes sense:
>
>
>
> - Keep this version TLS 1.3
>
> - For the next version of TLS, drop the 1.x and call it TLS 4
>
>
>
> --
>
> Tony Arcieri
>
> ___
> 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] post-handshake auth: multiple CertificateRequests, fewer replies?

2016-12-13 Thread David Benjamin 
Our implementation considers all post-handshake CertificateRequests to be a
fatal error to avoid this. We would do the same even with this proposal;
it's an unnecessary complexity (which translates to security risk). If the
protocol is such that the client will always bulk-disavow a burst of
unexpected CertificateRequests, the server shouldn't have sent them.

This was the motivation for wanting it controlled by application profile (
https://github.com/tlswg/tls13-spec/pull/680) and also our general dislike
of this feature. It's the sort of thing where semantics are very
application-specific and thus belongs in the application protocol, not TLS.

Alas, since HTTP/1.1 lacks a nice place to inject this, post-handshake auth
is needed to match the legacy renegotiation hack. But, with an application
protocol, we can make nice protocol-specific simplifying assumptions and
cut out all the pointless cases full generality forces a receiver to
tolerate.

For instance, in (unpipelined) HTTP/1.1:

1. A client first writes its entire HTTP request, then it tries to read the
HTTP response.
2. The server reads the HTTP request. If it decides it needs client auth,
it buffers the entire request and sends CertificateRequest. It then tries
to read the client Certificate..Finished before sending any part of the
HTTP response.
3. The client reads a CertificateRequest and considers it in response to
this HTTP request.
4. The client picks a client certificate and sends Certificate..Finished.
It goes back to reading the HTTP response.
5. The server reads this, checks it, and, if satisfied, sends the HTTP
response.
6. Any deviation from this exact flow is an unexpected post-handshake
message thus a protocol error. This includes:
  * Server sending CertificateRequest mid-response body.
  * Server sending 1,000 CertificateRequests when there's no HTTP request
on the pipe. [Although this'll just read as being in response to the next
HTTP request.]
  * Client sending application data sent between the HTTP request and
Certificate..Finished.
  * Client sending application data between Certificate and
CertificateVerify.
  * Client sending Certificate..Finished mid POST body.

The key here is "unexpected" is an application-specific idea. For most
applications, everything is unexpected and thus should be the default. For
applications that use this, "unexpected" is more complex.

In other words, you should think of post-handshake auth not as a thing the
TLS stack processes, but as an extra dimension of complexity in the TLS <->
application substrate. Just as application data record HTTP/1.1 syntax
error is protocol error, so should a CertificateRequest with HTTP/1.1
post-handshake-auth "syntax error".

David

On Tue, Dec 13, 2016 at 4:37 PM Benjamin Kaduk  wrote:

> 4.5.2 Post-Handshake Authentication notes that if a client receives
> multiple CertificateRequests, it can reply to them in a different order
> than they were received.  By my reading of the text, the client is still
> "obligated" to respond to all of them (but the server has to be able to
> receive an arbitrary number of messages before it gets back the response,
> so it's kind-of a weak obligation).  Would we want to weaken the
> restriction so that the client is only obligated to reply to at least one,
> similarly to how a peer can coalesce multiple KeyUpdate requests?  I
> understand that the setup is somewhat different, since the
> CertificateRequest comes with a context and could correspond to different
> application-level needs, but it seemed worth mentioning, since as we have
> discussed before generating the Finished message comes with some burden of
> handshake buffering/hash forking/etc.
>
> -Ben
> ___
> 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

[TLS] post-handshake auth: multiple CertificateRequests, fewer replies?

2016-12-13 Thread Benjamin Kaduk 
4.5.2 Post-Handshake Authentication notes that if a client receives
multiple CertificateRequests, it can reply to them in a different order
than they were received.  By my reading of the text, the client is still
"obligated" to respond to all of them (but the server has to be able to
receive an arbitrary number of messages before it gets back the
response, so it's kind-of a weak obligation).  Would we want to weaken
the restriction so that the client is only obligated to reply to at
least one, similarly to how a peer can coalesce multiple KeyUpdate
requests?  I understand that the setup is somewhat different, since the
CertificateRequest comes with a context and could correspond to
different application-level needs, but it seemed worth mentioning, since
as we have discussed before generating the Finished message comes with
some burden of handshake buffering/hash forking/etc.

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

Re: [TLS] PR#818: Consolidate "early_data" and "ticket_early_data_info"

2016-12-13 Thread Eric Rescorla 
Yes. From now on I will try to drink coffee before posting PRs.

On Tue, Dec 13, 2016 at 6:54 AM, Ilari Liusvaara 
wrote:

> On Tue, Dec 13, 2016 at 04:44:20AM -0800, Eric Rescorla wrote:
> > https://github.com/tlswg/tls13-spec/pull/818
> >
> > Steven Valdez and David Benjamin pointed out that now that we had one
> code
> > point
> > space we only needed one code point.
> >
> > Target merge date: Thursday
> >
>
> The structure definition has a case for hello_retry_request. Shouldn't
> that be encrypted_extensions?
>
>
> -Ilari
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR#818: Consolidate "early_data" and "ticket_early_data_info"

2016-12-13 Thread Ilari Liusvaara 
On Tue, Dec 13, 2016 at 04:44:20AM -0800, Eric Rescorla wrote:
> https://github.com/tlswg/tls13-spec/pull/818
> 
> Steven Valdez and David Benjamin pointed out that now that we had one code
> point
> space we only needed one code point.
> 
> Target merge date: Thursday
> 

The structure definition has a case for hello_retry_request. Shouldn't
that be encrypted_extensions?


-Ilari

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

[TLS] [Editorial Errata Reported] RFC5246 (4885)

2016-12-13 Thread RFC Errata System 
The following errata report has been submitted for RFC5246,
"The Transport Layer Security (TLS) Protocol Version 1.2".

--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5246&eid=4885

--
Type: Editorial
Reported by: Wail Yahyaoui 

Section: 6.1.

Original Text
-
   server random
  A 32-byte value provided by the server.

  These parameters are defined in the presentation language as:

  enum { server, client } ConnectionEnd;

Corrected Text
--
   server random
  A 32-byte value provided by the server.

   These parameters are defined in the presentation language as:

  enum { server, client } ConnectionEnd;

Notes
-
The line "These parameters are ..." after the list of parameters is at the same 
indentation level as the list of parameters, instead of coming back left by one 
level.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC5246 (draft-ietf-tls-rfc4346-bis-10)
--
Title   : The Transport Layer Security (TLS) Protocol Version 1.2
Publication Date: August 2008
Author(s)   : T. Dierks, E. Rescorla
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Area: Security
Stream  : IETF
Verifying Party : IESG

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

[TLS] PR#818: Consolidate "early_data" and "ticket_early_data_info"

2016-12-13 Thread Eric Rescorla 
https://github.com/tlswg/tls13-spec/pull/818

Steven Valdez and David Benjamin pointed out that now that we had one code
point
space we only needed one code point.

Target merge date: Thursday

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

Re: [TLS] Harmonizing 4492bis with TLS 1.3

2016-12-13 Thread Ilari Liusvaara 
On Tue, Dec 13, 2016 at 01:47:28PM +0200, Yoav Nir wrote:
> Hi
> 
> 1. Leave it as its current inconsistent state
> 2. Change 4492bis: 
>  a. no new curves for ed25519 and ed448.
>  b. Two new signature algorithms, and request values 7 and 8 for them.
>  c. new hash algorithm 0x08 and call it something like “intrinsic” 
> 3. Change TLS 1.3, by using 0x0007 for both EdDSA signature_algorithms and 
> add two values to supported_groups.
> 4. A hybrid of 2 & 3: 
>  a. No new curves for 4492bis
>  b. Two new signature algorithms with values 0x07 and 0x08
>  c. TLS 1.3 will modify the values to 0x0007 and 0x0008
> 
> There may be more options possible
> 
> What do people think?

I would prefer backporting TLS 1.3 methods, i.e. option 2. In fact, that
is what TLS library (btls) I have written does (it recognizes 0807 and
0808 even in TLS 1.2 and attempts to verify the signature).


-Ilari

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

[TLS] Pull Request #26 for RFC4492bis

2016-12-13 Thread Yoav Nir 
As Sean suggested, this PR removes two paragraphs from the Introduction 
section. They’re no longer needed in our opinion.

https://github.com/tlswg/rfc4492bis/pull/26 


If no objections are heard, I will merge this over the weekend.

Yoav

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

[TLS] Harmonizing 4492bis with TLS 1.3

2016-12-13 Thread Yoav Nir 
Hi

One issue that came up during WGLC for 4492bis is the way EdDSA signatures are 
mentioned in SignatureAndHashAlgorithm and in

In TLS 1.2 and 4492bis we have a SignatureAndHashAlgorithm struct with one byte 
for hash algorithm and another for signature algorithm.. The HashAlgorithm can 
be None(0), sha1(2), and a few more going up to sha512(6).  The 
SignatureAlgorithm can be anon(0), rsa(1), dsa(2), and ecdsa(3). 4492bis adds a 
new value to SignatureAlgorithm for EdDSA (TBD5).

Additionally, 4492bis requests two new NamedCurve values for ed25519 and ed448.

4492bis requires to use the None(0) HashAlgorithm with EdDSA.  So to declare 
support for both curves of EdDSA, you’re expected to have (0x00,TBD5) in 
signature_algorithms and both new curves in elliptic_curves.

TLS 1.3 replaces the signature_algorithms internal structure with a simple list 
of 16-bit values, but the old values are kept. So RSA with SHA1 is now 0x0201 
instead of (0x02,0x01).  However, for EdDSA the draft assigns two values: 
0x0807 for Ed25519 and 0x0808 for Ed448. Bringing that back to the TLS 1.2 
structure, it would mean that 0x08 is a new hash algorithm (that doesn’t really 
do anything) and 0x07 and 0x08 are two distinct signature algorithms (rather 
than the same algorithm, but with different curves).  So four options here:

1. Leave it as its current inconsistent state
2. Change 4492bis: 
 a. no new curves for ed25519 and ed448.
 b. Two new signature algorithms, and request values 7 and 8 for them.
 c. new hash algorithm 0x08 and call it something like “intrinsic” 
3. Change TLS 1.3, by using 0x0007 for both EdDSA signature_algorithms and add 
two values to supported_groups.
4. A hybrid of 2 & 3: 
 a. No new curves for 4492bis
 b. Two new signature algorithms with values 0x07 and 0x08
 c. TLS 1.3 will modify the values to 0x0007 and 0x0008

There may be more options possible

What do people think?

Yoav


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