Re: [TLS] What counts as the same ClientHello?

2017-09-04 Thread Ilari Liusvaara 
On Thu, Aug 31, 2017 at 09:50:07AM +1000, Martin Thomson wrote:
> On 30 August 2017 at 22:57, Ilari Liusvaara  wrote:
> > However, I identified a new category of extensions that I didn't notice
> > before: Dependent on altered extensions. There are no such standardized
> > extensions, but there is at least one proposal (in WG draft stage).
> 
> Is it possible that you could help us by sharing which one?

early_token_binding from  draft-ietf-tokbind-tls13-0rtt


However, looks like in this case, the server advertises support for
this in an NST extension, so at least it doesn't get thrown to random
servers.


Thinking about this more, it seems that any field or extension that
could be different across retry falls into one of three categories:

1) Something related to 0-RTT.
2) Something "feral": These things basically do not play by the normal
   rules[1].
3) Something that does not actually negotiate state[2].

Altering anything else will probably provoke Undefined Behavior due to
unknown state commitments.


[1] E.g., anything that goes into HelloRetryRequest or ServerHello,
and supported_versions.


[2] E.g. (Random), Padding.



-Ilari

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

Re: [TLS] What counts as the same ClientHello?

2017-09-04 Thread Hubert Kario 
On Tuesday, 29 August 2017 13:20:33 CEST Hannes Tschofenig wrote:
> Hi Noah, Todd, Ilari,
> 
> the HRR is used for two purposes, namely
>  * to report an error (with the key shares), and
>  * for DoS protection.
> 
> In both cases it feels excessive to require that the two ClientHellos
> are the same (with some minor exceptions). I see this as particularly
> problematic for the use with DTLS since with connectionless transport
> protocols the use of the HRR is obviously common and we are essentially
> wasting bytes on the wire for no good reason(with every handshake).
> 
> For the return-routability check there will be a cookie in the HRR and
> the RR check is useful primarily for connectionless transports.
> Re-transmitting the same information twice in this case is of doubtful
> value since (a) either the cookie contains the necessary info already or
> (b) the second ClientHello carries the relevant information.
> 
> Does this make sense?

Yes, though different Client Hello's can make the server select different set 
of algorithms (for example see Google selecting Chacha20 and AES-128-GCM over 
any else, but allowing the client to dictate which is actually negotiated if 
both are advertised). The second hello after modifications can cause the 
algorithm to select different values, despite HRR committing to specific set. 
Obviously that would be bad

Second thing is that if the second Client Hello is supposed to be identical to 
first one with few exceptions, the server does not need to parse or verify it 
fully before responding with Server Hello. 


-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  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] What counts as the same ClientHello?

2017-08-30 Thread Martin Thomson 
On 30 August 2017 at 22:57, Ilari Liusvaara  wrote:
> However, I identified a new category of extensions that I didn't notice
> before: Dependent on altered extensions. There are no such standardized
> extensions, but there is at least one proposal (in WG draft stage).

Is it possible that you could help us by sharing which one?

I would however suggest that this sort of dependency is already
possible.  We have a few places in our code that checks certain
conditions after extension processing because of dependencies between
extensions.  In particular, the pre_shared_key and early_data
extensions trigger a lot of cross checking because they change the
protocol in fairly fundamental ways.

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

Re: [TLS] What counts as the same ClientHello?

2017-08-30 Thread Ilari Liusvaara 
On Tue, Aug 29, 2017 at 01:29:55PM -0500, Benjamin Kaduk wrote:
> Hi Ilari,
> 
> Thanks for the by-extension categorization/breakdown.

Sigh, I missed cached_info, because that does not appear in TLS 1.3
extension lists. It falls into "unsafe to alter because unknown
commitments" category.

However, I identified a new category of extensions that I didn't notice
before: Dependent on altered extensions. There are no such standardized
extensions, but there is at least one proposal (in WG draft stage).


The latter kind of extensions is incompatible with MUST be the same
except  requirement.




-Ilari

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

Re: [TLS] What counts as the same ClientHello?

2017-08-29 Thread Ilari Liusvaara 
On Tue, Aug 29, 2017 at 02:40:56PM -0500, Benjamin Kaduk wrote:
> On 08/29/2017 02:02 PM, Eric Rescorla wrote:
> >
> > On Tue, Aug 29, 2017 at 11:29 AM, Benjamin Kaduk  > > wrote:
> >
> > Hi Ilari,
> >
> > Thanks for the by-extension categorization/breakdown.
> >
> > On 08/22/2017 03:13 PM, Ilari Liusvaara wrote:
> >> On Tue, Aug 22, 2017 at 05:50:49PM +, Noah Robbin wrote:
> >>> Hello Todd!
> >>>
> >>> I also did not see a reason why the random values had to be the same
> >>> but the language does mandate it.  
> >> I really do not think there is any technical or security reason why the
> >> randoms have to be the same. After all, TLS 1.3 does not directly use
> >> the randoms anywhere (they only affect things indirectly via hashes of
> >> the handshake).
> >
> > IIRC there was at some point talk of reconstructing the original
> > ClientHello based on the second one, but I guess we explicitly
> > decided to not allow that with
> > https://github.com/tlswg/tls13-spec/pull/678
> > 
> > 
> > .  So, I guess I am just saying that I agree.
> >
> >>> You make a good argument for not altering the padding on the second
> >>> ClientHello.
> >> I read that argument as "TLS 1.3 implementations should not need
> >> padding".
> >
> > IIRC at least some of the need for padding was due to middleboxes,
> > and I don't have data on to what extent existing middleboxes choke
> > on TLS 1.3 traffic.  (I believe others do have such data, though.)
> >
> >
> > The padding isn't for middleboxes, it's for terminating endpoints.
> >  in favor of removing these restrictions.
> >
> 
> No objection to removing the restriction from me.

Looking back at the list I posted, there are pretty few extensions that
are safe to alter or delete:

- key_share
- pre_shared_key
- early_data
- cookie
-  (not actually an extension)
- padding

The remaining extensions are either very much unsafe to alter due to
unknown commitments, or look potentially dangerous to security to alter
(with known commitments).
 
Hmm... Could pre_shared_key also belong to "potentially dangerous to
security to alter"? It is part of cipher negotiation after all, and
there is no bounding set, unlike with key_share.

The ClientHellos are tied together by handshake hash, which makes
attacks quite a lot more difficult, especially given that weak hashes
are unsafe for other reasons. Unfortunately, properly analyzing this is
way beyond my pay grade.



-Ilari

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

Re: [TLS] What counts as the same ClientHello?

2017-08-29 Thread Eric Rescorla 
On Tue, Aug 29, 2017 at 1:40 PM, Benjamin Kaduk  wrote:

> On 08/29/2017 02:02 PM, Eric Rescorla wrote:
>
>
> On Tue, Aug 29, 2017 at 11:29 AM, Benjamin Kaduk 
> wrote:
>
>> Hi Ilari,
>>
>> Thanks for the by-extension categorization/breakdown.
>>
>> On 08/22/2017 03:13 PM, Ilari Liusvaara wrote:
>>
>> On Tue, Aug 22, 2017 at 05:50:49PM +, Noah Robbin wrote:
>>
>> Hello Todd!
>>
>> I also did not see a reason why the random values had to be the same
>> but the language does mandate it.
>>
>> I really do not think there is any technical or security reason why the
>> randoms have to be the same. After all, TLS 1.3 does not directly use
>> the randoms anywhere (they only affect things indirectly via hashes of
>> the handshake).
>>
>>
>> IIRC there was at some point talk of reconstructing the original
>> ClientHello based on the second one, but I guess we explicitly decided to
>> not allow that with https://github.com/tlswg/tls13-spec/pull/678
>> 
>> .  So, I guess I am just saying that I agree.
>>
>> You make a good argument for not altering the padding on the second
>> ClientHello.
>>
>> I read that argument as "TLS 1.3 implementations should not need
>> padding".
>>
>>
>> IIRC at least some of the need for padding was due to middleboxes, and I
>> don't have data on to what extent existing middleboxes choke on TLS 1.3
>> traffic.  (I believe others do have such data, though.)
>>
>
> The padding isn't for middleboxes, it's for terminating endpoints.
>  in favor of removing these restrictions.
>
>
> No objection to removing the restriction from me.
>
>
>
>> Also, I came accross one edge case: What if client discovers that all
>> tickets in pre_shared_key are incompatible? The definition does not
>> allow 0 tickets, so choices are:
>>
>> 1) Leave all the tickets (which is not going to work) in.
>>
>> 2) Leave one ticket (which is not going to work) in.
>>
>> 3) Strip the entiere extension.
>>
>>
>>
>> My conceptual preference would be for (3), though I have a hard time
>> convincing myself that the current text actually permits doing so.  Maybe
>> it's simplest to just add a short not about removing the extension if no
>> compatible PSKs are known.
>>
>
> I think the current text says #1, which, AFAIK, doesn't cause any interop
> problems, so I think we should just leave it as-is.
>
>
> The editor's copy says the client can update the "pre_shared_key"
> extension by removing any PSKs that are incompatible with the server's
> indicated cipher suite, which is not exactly #1.
>

That'll teach me not to go look at the spec before I talk. Sounds like we
should perhaps just remove that text and do #1, but I could also live with
#3.

-Ekr


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

Re: [TLS] What counts as the same ClientHello?

2017-08-29 Thread Benjamin Kaduk 
On 08/29/2017 02:02 PM, Eric Rescorla wrote:
>
> On Tue, Aug 29, 2017 at 11:29 AM, Benjamin Kaduk  > wrote:
>
> Hi Ilari,
>
> Thanks for the by-extension categorization/breakdown.
>
> On 08/22/2017 03:13 PM, Ilari Liusvaara wrote:
>> On Tue, Aug 22, 2017 at 05:50:49PM +, Noah Robbin wrote:
>>> Hello Todd!
>>>
>>> I also did not see a reason why the random values had to be the same
>>> but the language does mandate it.  
>> I really do not think there is any technical or security reason why the
>> randoms have to be the same. After all, TLS 1.3 does not directly use
>> the randoms anywhere (they only affect things indirectly via hashes of
>> the handshake).
>
> IIRC there was at some point talk of reconstructing the original
> ClientHello based on the second one, but I guess we explicitly
> decided to not allow that with
> https://github.com/tlswg/tls13-spec/pull/678
> 
> 
> .  So, I guess I am just saying that I agree.
>
>>> You make a good argument for not altering the padding on the second
>>> ClientHello.
>> I read that argument as "TLS 1.3 implementations should not need
>> padding".
>
> IIRC at least some of the need for padding was due to middleboxes,
> and I don't have data on to what extent existing middleboxes choke
> on TLS 1.3 traffic.  (I believe others do have such data, though.)
>
>
> The padding isn't for middleboxes, it's for terminating endpoints.
>  in favor of removing these restrictions.
>

No objection to removing the restriction from me.

>  
>
>> Also, I came accross one edge case: What if client discovers that all
>> tickets in pre_shared_key are incompatible? The definition does not
>> allow 0 tickets, so choices are:
>>
>> 1) Leave all the tickets (which is not going to work) in.
>
>> 2) Leave one ticket (which is not going to work) in.
>
>> 3) Strip the entiere extension.
>>
>
> My conceptual preference would be for (3), though I have a hard
> time convincing myself that the current text actually permits
> doing so.  Maybe it's simplest to just add a short not about
> removing the extension if no compatible PSKs are known.
>
>
> I think the current text says #1, which, AFAIK, doesn't cause any
> interop problems, so I think we should just leave it as-is.
>

The editor's copy says the client can update the "pre_shared_key"
extension by removing any PSKs that are incompatible with the server's
indicated cipher suite, which is not exactly #1.

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

Re: [TLS] What counts as the same ClientHello?

2017-08-29 Thread Eric Rescorla 
On Tue, Aug 29, 2017 at 11:29 AM, Benjamin Kaduk  wrote:

> Hi Ilari,
>
> Thanks for the by-extension categorization/breakdown.
>
> On 08/22/2017 03:13 PM, Ilari Liusvaara wrote:
>
> On Tue, Aug 22, 2017 at 05:50:49PM +, Noah Robbin wrote:
>
> Hello Todd!
>
> I also did not see a reason why the random values had to be the same
> but the language does mandate it.
>
> I really do not think there is any technical or security reason why the
> randoms have to be the same. After all, TLS 1.3 does not directly use
> the randoms anywhere (they only affect things indirectly via hashes of
> the handshake).
>
>
> IIRC there was at some point talk of reconstructing the original
> ClientHello based on the second one, but I guess we explicitly decided to
> not allow that with https://github.com/tlswg/tls13-spec/pull/678 .  So, I
> guess I am just saying that I agree.
>
> You make a good argument for not altering the padding on the second
> ClientHello.
>
> I read that argument as "TLS 1.3 implementations should not need
> padding".
>
>
> IIRC at least some of the need for padding was due to middleboxes, and I
> don't have data on to what extent existing middleboxes choke on TLS 1.3
> traffic.  (I believe others do have such data, though.)
>

The padding isn't for middleboxes, it's for terminating endpoints.
 in favor of removing these restrictions.



> Also, I came accross one edge case: What if client discovers that all
> tickets in pre_shared_key are incompatible? The definition does not
> allow 0 tickets, so choices are:
>
> 1) Leave all the tickets (which is not going to work) in.
>
> 2) Leave one ticket (which is not going to work) in.
>
> 3) Strip the entiere extension.
>
>
>
> My conceptual preference would be for (3), though I have a hard time
> convincing myself that the current text actually permits doing so.  Maybe
> it's simplest to just add a short not about removing the extension if no
> compatible PSKs are known.
>

I think the current text says #1, which, AFAIK, doesn't cause any interop
problems, so I think we should just leave it as-is.

-Ekr


> -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

Re: [TLS] What counts as the same ClientHello?

2017-08-29 Thread Benjamin Kaduk 
Hi Ilari,

Thanks for the by-extension categorization/breakdown.

On 08/22/2017 03:13 PM, Ilari Liusvaara wrote:
> On Tue, Aug 22, 2017 at 05:50:49PM +, Noah Robbin wrote:
>> Hello Todd!
>>
>> I also did not see a reason why the random values had to be the same
>> but the language does mandate it.  
> I really do not think there is any technical or security reason why the
> randoms have to be the same. After all, TLS 1.3 does not directly use
> the randoms anywhere (they only affect things indirectly via hashes of
> the handshake).

IIRC there was at some point talk of reconstructing the original
ClientHello based on the second one, but I guess we explicitly decided
to not allow that with https://github.com/tlswg/tls13-spec/pull/678 . 
So, I guess I am just saying that I agree.

>> You make a good argument for not altering the padding on the second
>> ClientHello.
> I read that argument as "TLS 1.3 implementations should not need
> padding".

IIRC at least some of the need for padding was due to middleboxes, and I
don't have data on to what extent existing middleboxes choke on TLS 1.3
traffic.  (I believe others do have such data, though.)

> Also, I came accross one edge case: What if client discovers that all
> tickets in pre_shared_key are incompatible? The definition does not
> allow 0 tickets, so choices are:
>
> 1) Leave all the tickets (which is not going to work) in.
> 2) Leave one ticket (which is not going to work) in.
> 3) Strip the entiere extension.
>

My conceptual preference would be for (3), though I have a hard time
convincing myself that the current text actually permits doing so. 
Maybe it's simplest to just add a short not about removing the extension
if no compatible PSKs are known.

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

Re: [TLS] What counts as the same ClientHello?

2017-08-29 Thread Short, Todd 
Hannes:

The ID indicates that the two ClientHellos must be identical except for the 
fields explicitly listed. If you strongly disagree, then you should request a 
change to the ID. I understand your opinions on the matter; but as written, the 
ID requires those fields extensions to be the same. Here is the text in 
question, emphasis mine:


4.1.2.  
Client Hello


   When a client first connects to a server, it is REQUIRED to send the
   ClientHello as its first message.  The client will also send a
   ClientHello when the server has responded to its ClientHello with a
   HelloRetryRequest.  In that case, the client MUST send the same
   ClientHello (without modification) except:

   -  If a "key_share" extension was supplied in the HelloRetryRequest,
  replacing the list of shares with a list containing a single
  KeyShareEntry from the indicated group.

   -  Removing the "early_data" extension (Section 
4.2.9) if 
one was
  present.  Early data is not permitted after HelloRetryRequest.

   -  Including a "cookie" extension if one was provided in the
  HelloRetryRequest.

   -  Updating the "pre_shared_key" extension if present by recomputing
  the "obfuscated_ticket_age" and binder values and (optionally)
  removing any PSKs which are incompatible with the server's
  indicated cipher suite.


To avoid DOS and maintenance of state, the server should not maintain any of 
this information (except, perhaps indirectly via the cookie) if an HRR is 
returned. Thus the ClientHello is sent with all the information provided again. 
Yes, it’s a slight waste of bandwidth, but I’d rather use bandwidth that fleets 
away like time (use it or lose it), than memory in my device. This also permits 
multiple methods of implementation of the initial connection if all the 
information is provided again.

--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Aug 29, 2017, at 7:20 AM, Hannes Tschofenig 
> wrote:

Hi Noah, Todd, Ilari,

the HRR is used for two purposes, namely
* to report an error (with the key shares), and
* for DoS protection.

In both cases it feels excessive to require that the two ClientHellos
are the same (with some minor exceptions). I see this as particularly
problematic for the use with DTLS since with connectionless transport
protocols the use of the HRR is obviously common and we are essentially
wasting bytes on the wire for no good reason(with every handshake).

For the return-routability check there will be a cookie in the HRR and
the RR check is useful primarily for connectionless transports.
Re-transmitting the same information twice in this case is of doubtful
value since (a) either the cookie contains the necessary info already or
(b) the second ClientHello carries the relevant information.

Does this make sense?

Ciao
Hannes

On 08/22/2017 10:13 PM, Ilari Liusvaara wrote:
On Tue, Aug 22, 2017 at 05:50:49PM +, Noah Robbin wrote:
Hello Todd!

I also did not see a reason why the random values had to be the same
but the language does mandate it.

I really do not think there is any technical or security reason why the
randoms have to be the same. After all, TLS 1.3 does not directly use
the randoms anywhere (they only affect things indirectly via hashes of
the handshake).

You make a good argument for not altering the padding on the second
ClientHello.

I read that argument as "TLS 1.3 implementations should not need
padding".

I took a look at struct ClientHello and the extensions list:

There are technical reasons for not altering (the client has no idea
what the heck server did with these):

- server_name
- max_fragment_length
- status_request
- signature_algorithms
- use_srtp
- heartbeat
- application_layer_protocol_negotiation
- signed_certificate_timestamp
- client_certificate_type
- server_certificate_type
- psk_key_exchange_modes (due to side-effects)
- certificate_authorities
- post_handshake_auth

The following are explicitly listed as to be altered/deleted:

- key_share
- pre_shared_key
- early_data
- cookie

The following do not negotiate state:

- 
- padding

The following can't appear in ClientHello:

- oid_filters

The following client gains information about in HRR:

- 
- supported_groups (partially if key_share was not present).
- supported_versions (the client knows what server selected).


However the last group seems to be kind of things that are rather
questionable to prune (might be okay, but those make me wary).



Also, I came accross one edge case: What if client discovers that all
tickets in pre_shared_key are incompatible? The definition does not
allow 0 tickets, so choices are:

1) Leave all the tickets (which is not going to work) in.
2) Leave one ticket (which is not

Re: [TLS] What counts as the same ClientHello?

2017-08-29 Thread Hannes Tschofenig 
Hi Noah, Todd, Ilari,

the HRR is used for two purposes, namely
 * to report an error (with the key shares), and
 * for DoS protection.

In both cases it feels excessive to require that the two ClientHellos
are the same (with some minor exceptions). I see this as particularly
problematic for the use with DTLS since with connectionless transport
protocols the use of the HRR is obviously common and we are essentially
wasting bytes on the wire for no good reason(with every handshake).

For the return-routability check there will be a cookie in the HRR and
the RR check is useful primarily for connectionless transports.
Re-transmitting the same information twice in this case is of doubtful
value since (a) either the cookie contains the necessary info already or
(b) the second ClientHello carries the relevant information.

Does this make sense?

Ciao
Hannes

On 08/22/2017 10:13 PM, Ilari Liusvaara wrote:
> On Tue, Aug 22, 2017 at 05:50:49PM +, Noah Robbin wrote:
>> Hello Todd!
>>
>> I also did not see a reason why the random values had to be the same
>> but the language does mandate it.  
> 
> I really do not think there is any technical or security reason why the
> randoms have to be the same. After all, TLS 1.3 does not directly use
> the randoms anywhere (they only affect things indirectly via hashes of
> the handshake).
> 
>> You make a good argument for not altering the padding on the second
>> ClientHello.
> 
> I read that argument as "TLS 1.3 implementations should not need
> padding".
> 
> I took a look at struct ClientHello and the extensions list:
> 
> There are technical reasons for not altering (the client has no idea
> what the heck server did with these):
> 
> - server_name
> - max_fragment_length
> - status_request
> - signature_algorithms
> - use_srtp
> - heartbeat
> - application_layer_protocol_negotiation
> - signed_certificate_timestamp
> - client_certificate_type
> - server_certificate_type
> - psk_key_exchange_modes (due to side-effects)
> - certificate_authorities
> - post_handshake_auth
> 
> The following are explicitly listed as to be altered/deleted:
> 
> - key_share 
> - pre_shared_key
> - early_data
> - cookie
> 
> The following do not negotiate state:
> 
> - 
> - padding
> 
> The following can't appear in ClientHello:
> 
> - oid_filters
> 
> The following client gains information about in HRR:
> 
> - 
> - supported_groups (partially if key_share was not present).
> - supported_versions (the client knows what server selected).
> 
> 
> However the last group seems to be kind of things that are rather
> questionable to prune (might be okay, but those make me wary).
> 
> 
> 
> Also, I came accross one edge case: What if client discovers that all
> tickets in pre_shared_key are incompatible? The definition does not
> allow 0 tickets, so choices are:
> 
> 1) Leave all the tickets (which is not going to work) in.
> 2) Leave one ticket (which is not going to work) in.
> 3) Strip the entiere extension.
> 
> 
> 
> 
> -Ilari
> 
> ___
> 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] What counts as the same ClientHello?

2017-08-22 Thread Ilari Liusvaara 
On Tue, Aug 22, 2017 at 05:50:49PM +, Noah Robbin wrote:
> Hello Todd!
> 
> I also did not see a reason why the random values had to be the same
> but the language does mandate it.  

I really do not think there is any technical or security reason why the
randoms have to be the same. After all, TLS 1.3 does not directly use
the randoms anywhere (they only affect things indirectly via hashes of
the handshake).

> You make a good argument for not altering the padding on the second
> ClientHello.

I read that argument as "TLS 1.3 implementations should not need
padding".

I took a look at struct ClientHello and the extensions list:

There are technical reasons for not altering (the client has no idea
what the heck server did with these):

- server_name
- max_fragment_length
- status_request
- signature_algorithms
- use_srtp
- heartbeat
- application_layer_protocol_negotiation
- signed_certificate_timestamp
- client_certificate_type
- server_certificate_type
- psk_key_exchange_modes (due to side-effects)
- certificate_authorities
- post_handshake_auth

The following are explicitly listed as to be altered/deleted:

- key_share 
- pre_shared_key
- early_data
- cookie

The following do not negotiate state:

- 
- padding

The following can't appear in ClientHello:

- oid_filters

The following client gains information about in HRR:

- 
- supported_groups (partially if key_share was not present).
- supported_versions (the client knows what server selected).


However the last group seems to be kind of things that are rather
questionable to prune (might be okay, but those make me wary).



Also, I came accross one edge case: What if client discovers that all
tickets in pre_shared_key are incompatible? The definition does not
allow 0 tickets, so choices are:

1) Leave all the tickets (which is not going to work) in.
2) Leave one ticket (which is not going to work) in.
3) Strip the entiere extension.




-Ilari

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

Re: [TLS] What counts as the same ClientHello?

2017-08-22 Thread Noah Robbin 
Hello Todd!

I also did not see a reason why the random values had to be the same but the 
language does mandate it.  I see some of the TLS 1.3 clients using the same 
random and some are not.  There probably isn't anything that needs to be 
changed in the spec, but client implementers should be aware of the potential 
interoperability issue if the random is not maintained.

You make a good argument for not altering the padding on the second ClientHello.

-Noah

From: "Short, Todd" <tsh...@akamai.com>
Date: Tuesday, August 22, 2017 at 11:06 AM
To: Noah Robbin <noah_rob...@symantec.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: [EXT] Re: [TLS] What counts as the same ClientHello?

Hi Noah!

See below…

--
-Todd Short
// tsh...@akamai.com<mailto:tsh...@akamai.com>
// "One if by land, two if by sea, three if by the Internet."

On Aug 22, 2017, at 10:16 AM, Noah Robbin 
<noah_rob...@symantec.com<mailto:noah_rob...@symantec.com>> wrote:

Section 4.1.2 of the TLS 1.3 draft RFC specifies that the ClientHello sent in 
response to a HelloRetryRequest “MUST be the same (without modification) 
except” for a list of specific exceptions.  I have found one server that 
verifies that the random in the first ClientHello is the same as the random in 
the second ClientHello.  I have also found servers that accept the second 
ClientHello with a different random.  Many clients are sending a different 
random in the second ClientHello.
My reading of the specification is that the random must be the same, but if 
there are clients and servers taking different postures on this we will run 
into interop issues.

Based on the reading, the ClientRandom must be identical in both ClientHellos, 
although I do not see a reason that they need to be the same. It is likely that 
the server does not keep the original ClientHello around for comparison. More 
than likely the server generates a hash of the ClientHello and stuffs it into 
the cookie extension.

I also have two additional questions.
1 - The changes to key_share, early_data, and pre_shared_key extensions, and 
the addition of the cookie extension may change the overall length of the 
ClientHello such that it is now in the 256-511 range that some implementations 
have issues with.  Is it permissible to alter the padding extension?

IMHO, this should not matter with TLSv1.3. Those older, broken, implementations 
would not support TLSv1.3, and subsequently will not send back a 
HelloRetryRequest. I would hope that those older, broken implementations would 
be updated to fix their issue with ClientHello length when they upgrade to 
TLSv1.3.


2 -  The MUST language means that the order of the extensions must remain the 
same.  How strictly should a server enforce this and does this create a 
requirement for where the cookie extension should be inserted into the list?

The logical choice would be to append it to the end, so as to not change the 
order of the other extensions. But the pre-shared key must be last. So, never 
mind.

OpenSSL inserts the cookie after the key share, but before certificate 
authorities, basically the same place as the early data extension (which has to 
be removed), which would also be a logical choice.

Again, I don’t think that a server would keep an older ClientHello around, and 
would instead store the state in the Cookie extension (see section 4.2.2, 
second reason).



Thank you,
Noah Robbin

___
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls<https://clicktime.symantec.com/a/1/Hc3vWWWdeHQWbzqwXFDoReORbWrEgS7Xj0-226UDvNw=?d=OIu0gj9PUnG5fI3n8fnkhJPbc19DwgMnL_YUuxaZyO3xNzKoVqoZQuDpD5ddEu4ud53efTYZcT8zPL2SsnvMSKvvZPO7oIzsMbsqjaOhUWx7tust2YI7I9PDIW087Ipk22jyZWE6NeD5QyWhGFa9PSIXVDdeNroJkNltupwF5dreaQDSHp-C0TIcEsEGSV4rRRjqZiTF5LbTmT3qtbE7dRXudBjGQodj0FpYp5VDf4Nw5ZquSotvxu91g-xhHu5pCAfacjPNpnRUOlHz7iNNFEAmm8TZV0rB6McVAEDYJYMU1I9pH2KtWdeoUuNIB1wA4VfpTArDB8PB9t4P6ebbukHqfwGkyN7iGdc4dJGrQDZDwKnEQ5G8cxW8-oASO9PiP6l4FSNt=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls>

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

Re: [TLS] What counts as the same ClientHello?

2017-08-22 Thread Ilari Liusvaara 
On Tue, Aug 22, 2017 at 02:16:16PM +, Noah Robbin wrote:
> Section 4.1.2 of the TLS 1.3 draft RFC specifies that the ClientHello
> sent in response to a HelloRetryRequest “MUST be the same (without
> modification) except” for a list of specific exceptions.  I have
> found one server that verifies that the random in the first
> ClientHello is the same as the random in the second ClientHello.  I
> have also found servers that accept the second ClientHello with a
> different random.  Many clients are sending a different random in the
> second ClientHello.

The actual reason for this requirement appears to be that the server
might have committed several decisions that it can't back off of (e.g.,
ALPN), and which are not apparent in HelloRetryRequest.

The implementation I have written indeed does this sort of commitment
with every parameter that is actually used (but not ClientRandom,
because it isn't actually used in TLS 1.3). In fact, it does not even
check if the decisions are consistent with the new Client Hello (only
that the needed key share is present).




-Ilari

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

Re: [TLS] What counts as the same ClientHello?

2017-08-22 Thread Short, Todd 
Hi Noah!

See below…

--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Aug 22, 2017, at 10:16 AM, Noah Robbin 
> wrote:

Section 4.1.2 of the TLS 1.3 draft RFC specifies that the ClientHello sent in 
response to a HelloRetryRequest “MUST be the same (without modification) 
except” for a list of specific exceptions.  I have found one server that 
verifies that the random in the first ClientHello is the same as the random in 
the second ClientHello.  I have also found servers that accept the second 
ClientHello with a different random.  Many clients are sending a different 
random in the second ClientHello.
My reading of the specification is that the random must be the same, but if 
there are clients and servers taking different postures on this we will run 
into interop issues.

Based on the reading, the ClientRandom must be identical in both ClientHellos, 
although I do not see a reason that they need to be the same. It is likely that 
the server does not keep the original ClientHello around for comparison. More 
than likely the server generates a hash of the ClientHello and stuffs it into 
the cookie extension.

I also have two additional questions.
1 - The changes to key_share, early_data, and pre_shared_key extensions, and 
the addition of the cookie extension may change the overall length of the 
ClientHello such that it is now in the 256-511 range that some implementations 
have issues with.  Is it permissible to alter the padding extension?

IMHO, this should not matter with TLSv1.3. Those older, broken, implementations 
would not support TLSv1.3, and subsequently will not send back a 
HelloRetryRequest. I would hope that those older, broken implementations would 
be updated to fix their issue with ClientHello length when they upgrade to 
TLSv1.3.

2 -  The MUST language means that the order of the extensions must remain the 
same.  How strictly should a server enforce this and does this create a 
requirement for where the cookie extension should be inserted into the list?

The logical choice would be to append it to the end, so as to not change the 
order of the other extensions. But the pre-shared key must be last. So, never 
mind.

OpenSSL inserts the cookie after the key share, but before certificate 
authorities, basically the same place as the early data extension (which has to 
be removed), which would also be a logical choice.

Again, I don’t think that a server would keep an older ClientHello around, and 
would instead store the state in the Cookie extension (see section 4.2.2, 
second reason).


Thank you,
Noah Robbin

___
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] What counts as the same ClientHello?

2017-08-22 Thread Noah Robbin 
Section 4.1.2 of the TLS 1.3 draft RFC specifies that the ClientHello sent in 
response to a HelloRetryRequest “MUST be the same (without modification) 
except” for a list of specific exceptions.  I have found one server that 
verifies that the random in the first ClientHello is the same as the random in 
the second ClientHello.  I have also found servers that accept the second 
ClientHello with a different random.  Many clients are sending a different 
random in the second ClientHello.
My reading of the specification is that the random must be the same, but if 
there are clients and servers taking different postures on this we will run 
into interop issues.
I also have two additional questions.
1 - The changes to key_share, early_data, and pre_shared_key extensions, and 
the addition of the cookie extension may change the overall length of the 
ClientHello such that it is now in the 256-511 range that some implementations 
have issues with.  Is it permissible to alter the padding extension?
2 -  The MUST language means that the order of the extensions must remain the 
same.  How strictly should a server enforce this and does this create a 
requirement for where the cookie extension should be inserted into the list?

Thank you,
Noah Robbin

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