Re: [TLS] TLS Flags Open Question

[Sean Turner]

Yoav,

Thanks for pulling together this PR 
(https://github.com/tlswg/tls-flags/pull/5). There’s already some comments in 
the PR. If anybody has comments please jump in. Note that this is the last 
outstanding issue and we would like to close this in order to progress the I-D.

spt

> On Jan 1, 2021, at 16:36, Yoav Nir  wrote:
> 
> As all (OK, both) of the responses have been supportive, I have created a 
> pull request:
> 
> https://github.com/tlswg/tls-flags/pull/5
> 
> Yoav
> 
>> On 5 Dec 2020, at 17:04, Yoav Nir  wrote:
>> 
>> Hi.
>> 
>> At IETF 108 a question was raised about The TLS Flags extension.  What  
>> payloads on the server side can include this extension?
>> 
>> The “candidates” are ServerHello, EncryptedExtensions, Certificate, and 
>> NewSessionTicket.
>> 
>> The only one that is controversial here (I think) is ServerHello, because it 
>> is not encrypted.  Looking at the current list of extensions, I see that 
>> only 6 can go in ServerHello:
>>  • password_salt
>>  • tls_cert_with_extern_psk
>>  • supported_ekt_ciphers
>>  • pre_shared_key
>>  • supported_versions
>>  • key_share
>> 
>> Of those, only one would be (if it hadn’t already been standardized) a 
>> candidate for the TLS-Flags extension: tls_cert_with_extern_psk.  The RFC 
>> describes it with “The “tls_cert_with_extern_psk" extension is essentially a 
>> flag to use the external PSK in the key schedule”.  I don’t think it’s 
>> unreasonable to think that at some point there’s going to be another 
>> flag-like extension that will need to be signalled in ServerHello.
>> 
>> So the question for the group is, do we allow the flags extension (and the 
>> flags themselves) to be in ServerHello, or do we prohibit them for now, and 
>> if ever an extension does need to signal in ServerHello, it can update the 
>> TLS-Flags RFC at that time?
>> 
>> My vote would be to allow it in all places, and trust the process not to 
>> place flags that should be encrypted in payloads that aren’t, but either 
>> way, we need working group consensus.
>> 
>> Thanks
>> 
>> Yoav
>> 
> 
> ___
> 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] TLS Flags Open Question

[Yoav Nir]

As all (OK, both) of the responses have been supportive, I have created a pull 
request:

https://github.com/tlswg/tls-flags/pull/5 


Yoav

> On 5 Dec 2020, at 17:04, Yoav Nir  wrote:
> 
> Hi.
> 
> At IETF 108 a question was raised about The TLS Flags extension.  What  
> payloads on the server side can include this extension?
> 
> The “candidates” are ServerHello, EncryptedExtensions, Certificate, and 
> NewSessionTicket.
> 
> The only one that is controversial here (I think) is ServerHello, because it 
> is not encrypted.  Looking at the current list of extensions, I see that only 
> 6 can go in ServerHello:
> password_salt
> tls_cert_with_extern_psk
> supported_ekt_ciphers
> pre_shared_key
> supported_versions
> key_share
> 
> Of those, only one would be (if it hadn’t already been standardized) a 
> candidate for the TLS-Flags extension: tls_cert_with_extern_psk.  The RFC 
> describes it with “The “tls_cert_with_extern_psk" extension is essentially a 
> flag to use the external PSK in the key schedule”.  I don’t think it’s 
> unreasonable to think that at some point there’s going to be another 
> flag-like extension that will need to be signalled in ServerHello.
> 
> So the question for the group is, do we allow the flags extension (and the 
> flags themselves) to be in ServerHello, or do we prohibit them for now, and 
> if ever an extension does need to signal in ServerHello, it can update the 
> TLS-Flags RFC at that time?
> 
> My vote would be to allow it in all places, and trust the process not to 
> place flags that should be encrypted in payloads that aren’t, but either way, 
> we need working group consensus.
> 
> Thanks
> 
> Yoav
> 

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

Re: [TLS] TLS Flags Open Question

[David Benjamin]

On Sat, Dec 5, 2020 at 6:31 PM Eric Rescorla  wrote:

>
>
> On Sat, Dec 5, 2020 at 7:05 AM Yoav Nir  wrote:
>
>> Hi.
>>
>> At IETF 108 a question was raised about The TLS Flags extension.  What
>>  payloads on the server side can include this extension?
>>
>> The “candidates” are ServerHello, EncryptedExtensions, Certificate, and
>> NewSessionTicket.
>>
>
Should CertificateRequest be in that list? By the way, the text for section
3 might need tweaking. The rules for request vs. response extensions are
almost client/server, but not quite. Probably better to cite or adapt the
text in RFC8446, section 4.2.


> The only one that is controversial here (I think) is ServerHello, because
>> it is not encrypted.  Looking at the current list of extensions, I see that
>> only 6 can go in ServerHello:
>>
>>- password_salt
>>- tls_cert_with_extern_psk
>>- supported_ekt_ciphers
>>- pre_shared_key
>>- supported_versions
>>- key_share
>>
>>
>> Of those, only one would be (if it hadn’t already been standardized) a
>> candidate for the TLS-Flags extension: tls_cert_with_extern_psk.  The RFC
>> describes it with “The “tls_cert_with_extern_psk" extension is
>> essentially a flag to use the external PSK in the key schedule”.  I
>> don’t think it’s unreasonable to think that at some point there’s going to
>> be another flag-like extension that will need to be signalled in
>> ServerHello.
>>
>> So the question for the group is, do we allow the flags extension (and
>> the flags themselves) to be in ServerHello, or do we prohibit them for now,
>> and if ever an extension does need to signal in ServerHello, it can update
>> the TLS-Flags RFC at that time?
>>
>> My vote would be to allow it in all places, and trust the process not to
>> place flags that should be encrypted in payloads that aren’t, but either
>> way, we need working group consensus.
>>
>
> I agree with you that this is the right outcome.
>

I also agree.

I suspect it doesn't hugely matter since ServerHello carries response
messages. Until and unless we define a ServerHello flags extension, the no
unsolicited extensions rule and the no empty flags rule mean ServerHello
flags are effectively prohibited unless the client implements such an
extension. So that means we can punt to TLS-flags RFC. (Whereas I think
we'll need to sort out CertificateRequest now to avoid compat issues.) But
it's easy to allow it now, and saves us having to think about whether it's
safe to do later.

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

Re: [TLS] TLS Flags Open Question

[Eric Rescorla]

On Sat, Dec 5, 2020 at 7:05 AM Yoav Nir  wrote:

> Hi.
>
> At IETF 108 a question was raised about The TLS Flags extension.  What
>  payloads on the server side can include this extension?
>
> The “candidates” are ServerHello, EncryptedExtensions, Certificate, and
> NewSessionTicket.
>
> The only one that is controversial here (I think) is ServerHello, because
> it is not encrypted.  Looking at the current list of extensions, I see that
> only 6 can go in ServerHello:
>
>- password_salt
>- tls_cert_with_extern_psk
>- supported_ekt_ciphers
>- pre_shared_key
>- supported_versions
>- key_share
>
>
> Of those, only one would be (if it hadn’t already been standardized) a
> candidate for the TLS-Flags extension: tls_cert_with_extern_psk.  The RFC
> describes it with “The “tls_cert_with_extern_psk" extension is
> essentially a flag to use the external PSK in the key schedule”.  I don’t
> think it’s unreasonable to think that at some point there’s going to be
> another flag-like extension that will need to be signalled in ServerHello.
>
> So the question for the group is, do we allow the flags extension (and the
> flags themselves) to be in ServerHello, or do we prohibit them for now, and
> if ever an extension does need to signal in ServerHello, it can update the
> TLS-Flags RFC at that time?
>
> My vote would be to allow it in all places, and trust the process not to
> place flags that should be encrypted in payloads that aren’t, but either
> way, we need working group consensus.
>

I agree with you that this is the right outcome.

-Ekr


> Thanks
>
> Yoav
>
> ___
> 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