Re: [TLS] WGLC for draft-ietf-tls-exported-authenticator

[Nikos Mavrogiannopoulos]

On Thu, 2018-04-19 at 16:32 -0400, Sean Turner wrote:
> All,
> 
> This is the working group last call for the "Exported Authenticators
> in TLS" draft available at https://datatracker.ietf.org/doc/draft-iet
> f-tls-exported-authenticator/.  Please review the document and send
> your comments to the list by 2359 UTC on 4 April 2018.

I have not checked the mechanism, but I have few questions based on the
description in the introduction.
   "Post-handshake authentication is defined in TLS 1.3, but it has the
   disadvantage of requiring additional state to be stored in the TLS
   state machine and it composes poorly with multiplexed connection
   protocols like HTTP/2.  It is also only available for client
   authentication.  This mechanism is intended to be used as part of a
   replacement for post-handshake authentication in applications."

* Was this proposed to be included in TLS 1.3 as post-handshake
authentication mechanism instead?

* What are the actual problems that post-handshake authentication has
with HTTP/2?

regards,
Nikos

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

Re: [TLS] WGLC for draft-ietf-tls-exported-authenticator

[Tim Hollebeek]

I generally really like it.

 

My only comment is about the use of a zero byte as a separator in a string 
(4.2.2).

 

There are commonly used languages where this is likely to lead to 
implementation bugs, causing the signature to be computed over a shorter length 
than expected.

 

While I doubt this causes any problems other than failures and debugging pain, 
the first 64 bytes contain the octet 32; I don’t see any reason why byte 87 
can’t also be octet 32.

 

-Tim

 

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Nick Sullivan
Sent: Thursday, May 3, 2018 4:16 PM
To: Sean Turner 
Cc: TLS WG 
Subject: Re: [TLS] WGLC for draft-ietf-tls-exported-authenticator

 

Does anyone have any comments about the draft, criticisms, or votes of support?

 

Nick

On Thu, May 3, 2018 at 1:12 PM Sean Turner mailto:s...@sn3rd.com> > wrote:



> On Apr 21, 2018, at 10:25, Sean Turner   > wrote:
> 
> 
>> On Apr 19, 2018, at 16:32, Sean Turner >  > wrote:
>> 
>> All,
>> 
>> This is the working group last call for the "Exported Authenticators in TLS" 
>> draft available at 
>> https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ 
>>  . 
>>  Please review the document and send your comments to the list by 2359 UTC 
>> on 4 April 2018.
> 
> … 4 May 2018 ...

Just a reminder the WGLC ends tomorrow.

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



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-exported-authenticator

[Jonathan Hoyland]

Hi Nikos,

The problems post-handshake authentication has with HTTP/2 are described in
draft-ietf-httpbis-http2-secondary-certs-00

 a.k.a. draft-Bishop. See Section 1.2.3 in particular.

In brief, the problem is that requests and responses are multiplexed in
HTTP/2, and threfore there is not a tight coupling between TLS frames and
HTTP/2 streams.

With post-handshake authentication, the authentication happens in band, and
so the HTTP/2 layer doesn't have visibility into whether or not specific
data was sent before or after the authentication.

Regards,

Jonathan

On Fri, 4 May 2018 at 10:01 Nikos Mavrogiannopoulos  wrote:

> On Thu, 2018-04-19 at 16:32 -0400, Sean Turner wrote:
> > All,
> >
> > This is the working group last call for the "Exported Authenticators
> > in TLS" draft available at https://datatracker.ietf.org/doc/draft-iet
> > f-tls-exported-authenticator/.  Please review the document and send
> > your comments to the list by 2359 UTC on 4 April 2018.
>
> I have not checked the mechanism, but I have few questions based on the
> description in the introduction.
>"Post-handshake authentication is defined in TLS 1.3, but it has the
>disadvantage of requiring additional state to be stored in the TLS
>state machine and it composes poorly with multiplexed connection
>protocols like HTTP/2.  It is also only available for client
>authentication.  This mechanism is intended to be used as part of a
>replacement for post-handshake authentication in applications."
>
> * Was this proposed to be included in TLS 1.3 as post-handshake
> authentication mechanism instead?
>
> * What are the actual problems that post-handshake authentication has
> with HTTP/2?
>
> regards,
> Nikos
>
> ___
> 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] WGLC for draft-ietf-tls-exported-authenticator

[Roelof duToit]

How will this (and any mechanism built on top of RFC 5705 exported key 
material) interoperate with middleboxes?  This use of the mechanism is not 
negotiated on the TLS level, so there is no extension for the middlebox to 
strip that would warn the endpoints not to use exported authenticators.  Are 
application level proxies the only compatible middleboxes?

—Roelof


> On Apr 19, 2018, at 4:32 PM, Sean Turner  wrote:
> 
> All,
> 
> This is the working group last call for the "Exported Authenticators in TLS" 
> draft available at 
> https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/.  
> Please review the document and send your comments to the list by 2359 UTC on 
> 4 April 2018.
> 
> Thanks - J&S
> ___
> 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] Reserve or close HashAlgorithm and SignatureAlgorithm registries?

[Sean Turner]

The open issue in draft-ietf-tls-iana-registry-updates is whether we should 
close the registries or simply reserve the remaining values.  I’ve submitted 
the following PR to simply reserve the values and point to the SignatureScheme 
registry for 1.3 values:
https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/75
I did this because a) closing a registry is really just symbolic; a draft (or 
the IESG) can later reopen the registry, and b) At least person has indicated 
they might want code points for a TLS1.2 implementation.  Regardless of what we 
do we should point to the SignatureScheme registry for 1.3, but I just don’t 
really see the point in “closing” the registry.  If this PR makes you really 
sad please let us know.

Please note that the gh editor’s copy also includes the IESG-related changes.  
I’d characterize most of them as good catches (e.g., cached_info was missing) 
and consistency (e.g., some of the DE language was not consistent).

I’d also like to point out that IANA specifically asked about the DE doing such 
a minimal review and we let them know that yes in some cases it was going to be 
just that.  But, this also made us consider adding the text that was in the 
security considerations and elsewhere to every DE-related note.  It is clearer 
now what the DE will do in the notes in case people don’t want to take the time 
to review this draft, which is actually what I think happens in most cases.

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

Re: [TLS] Reserve or close HashAlgorithm and SignatureAlgorithm registries?

[Russ Housley]

I think that reserving them is the right thing for now.  TLS 1.2 and earlier 
will take a while to disappear, so the ability to assign more values if there 
is a huge surprise seems prudent.

Russ


> On May 4, 2018, at 3:54 PM, Sean Turner  wrote:
> 
> The open issue in draft-ietf-tls-iana-registry-updates is whether we should 
> close the registries or simply reserve the remaining values.  I’ve submitted 
> the following PR to simply reserve the values and point to the 
> SignatureScheme registry for 1.3 values:
> https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/75
> I did this because a) closing a registry is really just symbolic; a draft (or 
> the IESG) can later reopen the registry, and b) At least person has indicated 
> they might want code points for a TLS1.2 implementation.  Regardless of what 
> we do we should point to the SignatureScheme registry for 1.3, but I just 
> don’t really see the point in “closing” the registry.  If this PR makes you 
> really sad please let us know.
> 
> Please note that the gh editor’s copy also includes the IESG-related changes. 
>  I’d characterize most of them as good catches (e.g., cached_info was 
> missing) and consistency (e.g., some of the DE language was not consistent).
> 
> I’d also like to point out that IANA specifically asked about the DE doing 
> such a minimal review and we let them know that yes in some cases it was 
> going to be just that.  But, this also made us consider adding the text that 
> was in the security considerations and elsewhere to every DE-related note.  
> It is clearer now what the DE will do in the notes in case people don’t want 
> to take the time to review this draft, which is actually what I think happens 
> in most cases.
> 
> spt
> ___
> 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] WGLC for draft-ietf-tls-exported-authenticator

[Christopher Wood]

I sent in one editorial PR as well. Pending the suggested change, I think
the document is ready to go.

Best,
Chris
On Thu, May 3, 2018 at 7:24 PM Martin Thomson 
wrote:

> I've already provided enough input on this draft, but I sent in a few
> editorial PRs.

> Otherwise, this looks fine to go from my perspective.  I would like to see
> some other opinions though, I'm probably too close to this.

> ___
> 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] WGLC for draft-ietf-tls-exported-authenticator

[Benjamin Kaduk]

On Thu, Apr 19, 2018 at 04:32:55PM -0400, Sean Turner wrote:
> All,
> 
> This is the working group last call for the "Exported Authenticators in TLS" 
> draft available at 
> https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/.  
> Please review the document and send your comments to the list by 2359 UTC on 
> 4 April 2018.

Are we using values in the same certificate_request_context space as those that
in-TLS post-handshake authentication would use?  If so, we should probably have
some text in Section 3 (and maybe more explanation in Section 5.2 as well?)
about the application coordinating with the TLS stack to avoid conflicts (since
just from a data structure point of view the application could send a
CertficiateRequest without checking with the TLS stack).  We may also need the
TLS stack to accound for context values chosen arbitrarily for spontaneous
authentications.  The API considerations might also be more clear that there
are different spaces for the context values for server auth and client auth.

Section 4.1 talks of the length of the exporter value in terms of the length of 
the
TLS PRF hash, adding that cipher suites not using TLS PRF have to define a hash 
function.
But TLS 1.3 ciphersuites do not use the TLS PRF and we say nothing about them...

It doesn't look like we adapted to the addition of the signature_algorithms_cert
extension in TLS 1.3.

-Ben (with no hats)

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

Re: [TLS] WGLC for draft-ietf-tls-exported-authenticator

[Benjamin Kaduk]

On Fri, May 04, 2018 at 11:20:55AM -0400, Roelof duToit wrote:
> How will this (and any mechanism built on top of RFC 5705 exported key 
> material) interoperate with middleboxes?  This use of the mechanism is not 
> negotiated on the TLS level, so there is no extension for the middlebox to 
> strip that would warn the endpoints not to use exported authenticators.  Are 
> application level proxies the only compatible middleboxes?

I'm not sure I properly understand the question, in particular what kind of
middlebox you're considering.  Note that application protocols will need to
have some way to negotiate the use of this functionality, which presumably a
middlebox could also inspect.

-Ben

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