Re: [TLS] [Editorial Errata Reported] RFC8446 (6204)

2020-06-04 Thread Russ Housley
Eric:

> On Wed, Jun 3, 2020 at 6:07 PM Martin Thomson  > wrote:
> I think that this is a useful erratum and it should be approved/HFDU.  The 
> extension to which this text alludes is RFC 8773, not post_handshake_auth.
> 
> Yes, although 8773 actually is not super-clear about post-handshake, so 
> that's actually something we should clarify there.

RFC 8773 is not intended for post handshake.  So, I never thought about that.  
What is the use case you are considering?

Russ

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


Re: [TLS] [Editorial Errata Reported] RFC8446 (6204)

2020-06-04 Thread Russ Housley
Martin:

> I think that this is a useful erratum and it should be approved/HFDU.  The 
> extension to which this text alludes is RFC 8773, not post_handshake_auth.
> 
> There is one other piece to this that is very confusing, and less clear.
> 
> "Servers which are authenticating with a PSK MUST NOT send the 
> CertificateRequest message in the main handshake, though they MAY send it in 
> post-handshake authentication (see Section 4.6.2) provided that the client 
> has sent the "post_handshake_auth" extension (see Section 4.2.6)."
> 
> The motivation is the attack that Sam Scott et. al. found in their analysis 
> of resumption:  
> https://mailarchive.ietf.org/arch/msg/tls/TugB5ddJu3nYg7chcyeIyUqWSbA/  
> However, this statement is unclear on whether it applies to external, 
> resumption, or both types of PSK, but without qualification as it is you 
> might be forgiven for thinking that it is both.
> 
> However, the document already says:
> 
> "It is unsafe to use certificate-based client authentication when the client 
> might potentially share the same PSK/key-id pair with two different 
> endpoints."
> 
> So I think that the right interpretation is that this statement applies to "a 
> resumption PSK" only.
> 
> If people agree with this interpretation, then I will file another erratum of 
> the form:
> 
> OLD:
> Servers which are authenticating with a PSK MUST NOT send the 
> CertificateRequest message in the main handshake, [...]
> NEW:
> Servers which are authenticating with a resumption PSK MUST NOT send the 
> CertificateRequest message in the main handshake, [...]

Works for me too.

Russ

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


Re: [TLS] [Editorial Errata Reported] RFC8446 (6204)

2020-06-04 Thread Eric Rescorla
On Thu, Jun 4, 2020 at 8:46 AM Russ Housley  wrote:

> Eric:
>
> On Wed, Jun 3, 2020 at 6:07 PM Martin Thomson  wrote:
>
>> I think that this is a useful erratum and it should be approved/HFDU.
>> The extension to which this text alludes is RFC 8773, not
>> post_handshake_auth.
>>
>
> Yes, although 8773 actually is not super-clear about post-handshake, so
> that's actually something we should clarify there.
>
>
> RFC 8773 is not intended for post handshake.  So, I never thought about
> that.  What is the use case you are considering?
>

I don't have one. I'm just trying to make sure things are clear. perhaps an
erratum on 8773 to make ultra clear?

-Ekr


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


Re: [TLS] [Editorial Errata Reported] RFC8446 (6204)

2020-06-04 Thread Russ Housley
Eric:

>> On Wed, Jun 3, 2020 at 6:07 PM Martin Thomson > > wrote:
>> I think that this is a useful erratum and it should be approved/HFDU.  The 
>> extension to which this text alludes is RFC 8773, not post_handshake_auth.
>> 
>> Yes, although 8773 actually is not super-clear about post-handshake, so 
>> that's actually something we should clarify there.
> 
> RFC 8773 is not intended for post handshake.  So, I never thought about that. 
>  What is the use case you are considering?
> 
> I don't have one. I'm just trying to make sure things are clear. perhaps an 
> erratum on 8773 to make ultra clear?

I do not find it unclear.  What do you have in mind?

Russ

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


Re: [TLS] [Editorial Errata Reported] RFC8446 (6204)

2020-06-04 Thread Eric Rescorla
On Thu, Jun 4, 2020 at 9:24 AM Russ Housley  wrote:

> Eric:
>
> On Wed, Jun 3, 2020 at 6:07 PM Martin Thomson  wrote:
>>
>>> I think that this is a useful erratum and it should be approved/HFDU.
>>> The extension to which this text alludes is RFC 8773, not
>>> post_handshake_auth.
>>>
>>
>> Yes, although 8773 actually is not super-clear about post-handshake, so
>> that's actually something we should clarify there.
>>
>>
>> RFC 8773 is not intended for post handshake.  So, I never thought about
>> that.  What is the use case you are considering?
>>
>
> I don't have one. I'm just trying to make sure things are clear. perhaps
> an erratum on 8773 to make ultra clear?
>
>
> I do not find it unclear.
>

I am looking at 5.2 which seems like it could be more precise.



> What do you have in mind?
>

Changing:
   TLS 1.3 does not permit the server to send a CertificateRequest
   message when a PSK is being used. This restriction is removed when
   the "tls_cert_with_extern_psk" extension is negotiated, allowing
   certificate-based authentication for both the client and the
   server. To: TLS 1.3 does not permit the server to send a
   CertificateRequest message when a PSK is being used. This restriction
   is removed when the "tls_cert_with_extern_psk" extension is
   negotiated, allowing certificate-based authentication for both the
   client and the server.

To:
   TLS 1.3 does not permit the server to send a CertificateRequest
   message when a PSK is being used. This restriction is removed when
   the "tls_cert_with_extern_psk" extension is negotiated, allowing
   certificate-based authentication for both the client and the
   server. To: TLS 1.3 does not permit the server to send a
   CertificateRequest message when a PSK is being used. This
   restriction is removed for the main handshake when the
   "tls_cert_with_extern_psk" extension is negotiated, allowing
   certificate-based authentication for both the client and the
   server. This extension has no impact on external PSK usage
   with post-handshake authentication, which is prohibited by
   TLS 1.3.

-Ekr

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


Re: [TLS] [Editorial Errata Reported] RFC8446 (6204)

2020-06-04 Thread Russ Housley


> On Jun 4, 2020, at 12:37 PM, Eric Rescorla  wrote:
> 
> 
> 
> On Thu, Jun 4, 2020 at 9:24 AM Russ Housley  > wrote:
> Eric:
> 
>>> On Wed, Jun 3, 2020 at 6:07 PM Martin Thomson >> > wrote:
>>> I think that this is a useful erratum and it should be approved/HFDU.  The 
>>> extension to which this text alludes is RFC 8773, not post_handshake_auth.
>>> 
>>> Yes, although 8773 actually is not super-clear about post-handshake, so 
>>> that's actually something we should clarify there.
>> 
>> RFC 8773 is not intended for post handshake.  So, I never thought about 
>> that.  What is the use case you are considering?
>> 
>> I don't have one. I'm just trying to make sure things are clear. perhaps an 
>> erratum on 8773 to make ultra clear?
> 
> I do not find it unclear.  
> 
> I am looking at 5.2 which seems like it could be more precise.
> 
>  
> What do you have in mind?
> 
> Changing:
>TLS 1.3 does not permit the server to send a CertificateRequest
>message when a PSK is being used. This restriction is removed when
>the "tls_cert_with_extern_psk" extension is negotiated, allowing
>certificate-based authentication for both the client and the
>server. To: TLS 1.3 does not permit the server to send a
>CertificateRequest message when a PSK is being used. This restriction
>is removed when the "tls_cert_with_extern_psk" extension is
>negotiated, allowing certificate-based authentication for both the
>client and the server.
> 
> To:
>TLS 1.3 does not permit the server to send a CertificateRequest
>message when a PSK is being used. This restriction is removed when
>the "tls_cert_with_extern_psk" extension is negotiated, allowing
>certificate-based authentication for both the client and the
>server. To: TLS 1.3 does not permit the server to send a
>CertificateRequest message when a PSK is being used. This
>restriction is removed for the main handshake when the
>"tls_cert_with_extern_psk" extension is negotiated, allowing
>certificate-based authentication for both the client and the
>server. This extension has no impact on external PSK usage
>with post-handshake authentication, which is prohibited by
>TLS 1.3.

This works for me.  I wonder if "initial handshake" would be better than "main 
handshake"

Russ


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


Re: [TLS] 3rd WGLC for draft-ietf-tls-exported-authenticators

2020-06-04 Thread Sean Turner
Another reminder ...

> On May 22, 2020, at 09:23, Sean Turner  wrote:
> 
> This is the 3rd WGLC for "Exported Authenticators in TLS" draft available at 
> https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/. The 
> secdir review during IETF LC raised some issues and as a result there have 
> been a couple of new versions. Please respond to the list with any comments 
> by 2359 UTC on 8 June 2020.
> 
> Cheers,
> spt (for the chairs)

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