Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Joseph Salowey]

On Mon, Feb 1, 2021 at 8:23 PM Benjamin Kaduk  wrote:

> On Mon, Feb 01, 2021 at 07:09:14AM -0500, Alan DeKok wrote:
> > On Jan 31, 2021, at 9:16 PM, Benjamin Kaduk  wrote:
> > > That's a scenario that I was starting to puzzle over this weekend as
> well
> > > -- with EAP-Success "completely unauthenticated", it would be fairly
> easy
> > > for an on-path attacker to send the EAP-Success the EAP peer was
> expecting
> > > and make the EAP peer think things succeeded even if the server had
> > > rejected the client cert.
> >
> >   Yes.
> >
> > >  Now, a server that has rejected the client cert
> > > is hopefully not going to be exporting the keys and continuing to run
> the
> > > next steps of protocol operation, but to some extent it seems that the
> > > security of the system as a whole relies on the server operating
> correctly
> > > in this regard.
> >
> >   The TLS exporter keys are used for 802.1X / MacSec.  But they're not
> always used.
>
> Somehow I had convinced myself that the EMSK was only sometimes used, but
> MSK was always used.  If MSK is always used, then key confirmation of the
> MSK can play the role of handshake (and client authentication)
> confirmation, but otherwise I seem to be coming around to your "4.5 round
> trips is unavoidable" conclusion.  I'm not sure how clear-cut a distinction
> there is between cases that use the keys and those that don't, such that
> the last round trip could be shaved off when the exported key is used for
> key confirmation...
>
> > > ... it
> > > seems like a lot of what is being described as desired here ends up
> relying
> > > on ordering between application data and handshake messages.
> >
> >   I think there's no implementation issue here.  The draft should be
> clearer that there's no guaranteed ordering.
>
> I was going to stick this in a reply to Joe (at
> https://mailarchive.ietf.org/arch/browse/emu/), but maybe I can sneak it
> in
> here and save a message in everybody's inbox.
>
> My understanding (based on
> https://tools.ietf.org/html/rfc5216#section-2.1.5) is that EAP-TLS
> fragments TLS records, or in some cases, groups of records, and the first
> fragment includes a four-byte length field for the total message being
> fragmented.  Recalling that a given TLS record can only have payload of a
> single content type, in the scenario with a 0x00 confirmation message and a
> NewSessionTicket, that means one record with inner type application data
> and another record with inner type handshake.  If they are both grouped
> together to the EAP-TLS fragmentation engine, then I agree that there is no
> issue and a proper implementation should be waiting to reassemble the whole
> fragmented bundle, including both records, before finalizing processing.
> But is it also allowed to fragment the two records separately?  I didn't
> see anything that required the entire TLS flight of messages to be
> a single fragmentation input, and it's in the case that the 0x00 and
> NewSessionTicket are fragmented separately that the ordering becomes
> relevant -- if the 0x00 is fragmented first then the peer gets the complete
> fragmented message, sees the commitment message, and prepares its
> authentication flight in the EAP-Response, and based on the supposed
> commitment semantics would then somehow be expected to reject an
> EAP-Request with NewSessionTicket as breaking the commitment.  (Assuming it
> had a way to tell it was a handshake message at all, that is...)
>
> I'd love to hear what I am missing that makes the above incorrect, and/or
> that we have a way to require the NewSessionTicket and commitment message
> to be part of the same fragmentation unit.
>
>
[Joe] I would interpret the commitment message to mean that there are no
more handshake messages coming after completing the processing of this
entire EAP message.  An implementation should not stop processing the
packet in the middle of an EAP-TLS message, even if it is fragmented.  The
whole message should be consumed.


> > > (A lot of my hedging in messages on this thread is because I also don't
> > > really understand why the message is there.)
> > > I believe I read somewhere that it stemmed from the change in who
> speaks
> > > last in the TLS handshake, but am a bit hazy on how that implies it is
> > > needed.
> >
> >   I would like clarification on just what that message *means*.  If we
> want an explicit EAP layer signal that the server saw the client cert and
> authenticated it, then we MUST NOT send any such signal until after the
> server has seen the client cert.  And because the EAP-Success is sent all
> alone, we MUST then have another full round of TLS exchange, before the
> final EAP-Success.   i.e.
> >
> >
> > EAP-TLS Peer  EAP-TLS Server
> >
> >  EAP-Request/
> >  <  Identity
> > EAP-Response/
> > Identity (Privacy-Friendly)  

[TLS] EAP-TLS: can someone clue me in?

[Watson Ladd]

Dear all,

After reading all 50 odd emails I'm perpetually confused as to what is
going on, each email and the doc confusing me further. It seems that
similar to QUIC there is an attempt to put TLS over a non TCP
transport and then use for signaling user authentication via X509
certificates, and that the server needs to indicate whether
authentication is successful or not.

Looking at 8446 E.1.2  it seems that only application layer for TLS
messages from the server can confirm this, but I'm not sure that this
actually is the conclusion of all those emails. The other conclusion I
draw is just as QUIC required special adaption, we may want to
consider embedding TLS in other protocols more systemically, although
I have no applications at this time.

Sincerely,
Watson

-- 
Astra mortemque praestare gradatim

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

[TLS] Moved to Historic: RFC 5469 on DES and IDEA Cipher Suites for Transport Layer Security (TLS)

[rfc-editor]

RFC 5469 has been reclassified as Historic.


RFC 5469

Title:  DES and IDEA Cipher Suites 
for Transport Layer Security (TLS) 
Author: P. Eronen, Ed.
Status: Historic
Stream: IETF
Date:   February 2009
Pages:  4
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-tls-des-idea-02.txt

URL:https://www.rfc-editor.org/info/rfc5469

DOI:10.17487/RFC5469

Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC
4346) include cipher suites based on DES (Data Encryption Standard)
and IDEA (International Data Encryption Algorithm) algorithms.  DES
(when used in single-DES mode) and IDEA are no longer recommended for
general use in TLS, and have been removed from TLS version 1.2 (RFC
5246).  This document specifies these cipher suites for completeness
and discusses reasons why their use is no longer recommended.  

This document is a product of the Transport Layer Security Working Group of the 
IETF.


HISTORIC: This memo defines a Historic Document for the Internet
community.  It does not specify an Internet standard of any kind.
Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC

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

[TLS] Moved to Historic: RFC 4347 on Datagram Transport Layer Security

[rfc-editor]

RFC 4347 has been reclassified as Historic.


RFC 4347

Title:  Datagram Transport Layer Security 
Author: E. Rescorla,
N. Modadugu
Status: Historic
Stream: IETF
Date:   April 2006
Pages:  25
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-rescorla-dtls-05.txt

URL:https://www.rfc-editor.org/info/rfc4347

DOI:10.17487/RFC4347

This document specifies Version 1.0 of the Datagram Transport Layer
Security (DTLS) protocol.  The DTLS protocol provides communications
privacy for datagram protocols.  The protocol allows client/server
applications to communicate in a way that is designed to prevent
eavesdropping, tampering, or message forgery.  The DTLS protocol is
based on the Transport Layer Security (TLS) protocol and provides
equivalent security guarantees.  Datagram semantics of the underlying
transport are preserved by the DTLS protocol.


HISTORIC: This memo defines a Historic Document for the Internet
community.  It does not specify an Internet standard of any kind.
Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC

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

[TLS] Moved to Historic: RFC 4346 on The Transport Layer Security (TLS) Protocol Version 1.1

[rfc-editor]

RFC 4346 has been reclassified as Historic.


RFC 4346

Title:  The Transport Layer Security (TLS) 
Protocol Version 1.1 
Author: T. Dierks,
E. Rescorla
Status: Historic
Stream: IETF
Date:   April 2006
Pages:  87
Obsoletes:  RFC 2246

I-D Tag:draft-ietf-tls-rfc2246-bis-13.txt

URL:https://www.rfc-editor.org/info/rfc4346

DOI:10.17487/RFC4346

This document specifies Version 1.1 of the Transport Layer Security
(TLS) protocol.  The TLS protocol provides communications security
over the Internet.  The protocol allows client/server applications to
communicate in a way that is designed to prevent eavesdropping,
tampering, or message forgery.

This document is a product of the Transport Layer Security Working Group of the 
IETF.


HISTORIC: This memo defines a Historic Document for the Internet
community.  It does not specify an Internet standard of any kind.
Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC

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

[TLS] Moved to Historic: RFC 2246 on The TLS Protocol Version 1.0

[rfc-editor]

RFC 2246 has been reclassified as Historic.


RFC 2246

Title:  The TLS Protocol Version 1.0 
Author: T. Dierks,
C. Allen
Status: Historic
Stream: IETF
Date:   January 1999
Pages:  80
Updates/Obsoletes/SeeAlso:   None

URL:https://www.rfc-editor.org/info/rfc2246

DOI:10.17487/RFC2246

This document specifies Version 1.0 of the Transport Layer Security (TLS) 
protocol. The TLS protocol provides communications privacy over the Internet. 
The protocol allows client/server applications to communicate in a way that is 
designed to prevent eavesdropping, tampering, or message forgery.

This document is a product of the Transport Layer Security Working Group of the 
IETF.


HISTORIC: This memo defines a Historic Document for the Internet
community.  It does not specify an Internet standard of any kind.
Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC

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

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

On Mon, Feb 01, 2021 at 07:09:14AM -0500, Alan DeKok wrote:
> On Jan 31, 2021, at 9:16 PM, Benjamin Kaduk  wrote:
> > That's a scenario that I was starting to puzzle over this weekend as well
> > -- with EAP-Success "completely unauthenticated", it would be fairly easy
> > for an on-path attacker to send the EAP-Success the EAP peer was expecting
> > and make the EAP peer think things succeeded even if the server had
> > rejected the client cert.
> 
>   Yes.
> 
> >  Now, a server that has rejected the client cert
> > is hopefully not going to be exporting the keys and continuing to run the
> > next steps of protocol operation, but to some extent it seems that the
> > security of the system as a whole relies on the server operating correctly
> > in this regard.
> 
>   The TLS exporter keys are used for 802.1X / MacSec.  But they're not always 
> used.

Somehow I had convinced myself that the EMSK was only sometimes used, but
MSK was always used.  If MSK is always used, then key confirmation of the
MSK can play the role of handshake (and client authentication)
confirmation, but otherwise I seem to be coming around to your "4.5 round
trips is unavoidable" conclusion.  I'm not sure how clear-cut a distinction
there is between cases that use the keys and those that don't, such that
the last round trip could be shaved off when the exported key is used for
key confirmation...

> > ... it
> > seems like a lot of what is being described as desired here ends up relying
> > on ordering between application data and handshake messages.
> 
>   I think there's no implementation issue here.  The draft should be clearer 
> that there's no guaranteed ordering.

I was going to stick this in a reply to Joe (at
https://mailarchive.ietf.org/arch/browse/emu/), but maybe I can sneak it in
here and save a message in everybody's inbox.

My understanding (based on
https://tools.ietf.org/html/rfc5216#section-2.1.5) is that EAP-TLS
fragments TLS records, or in some cases, groups of records, and the first
fragment includes a four-byte length field for the total message being
fragmented.  Recalling that a given TLS record can only have payload of a
single content type, in the scenario with a 0x00 confirmation message and a
NewSessionTicket, that means one record with inner type application data
and another record with inner type handshake.  If they are both grouped
together to the EAP-TLS fragmentation engine, then I agree that there is no
issue and a proper implementation should be waiting to reassemble the whole
fragmented bundle, including both records, before finalizing processing.
But is it also allowed to fragment the two records separately?  I didn't
see anything that required the entire TLS flight of messages to be
a single fragmentation input, and it's in the case that the 0x00 and
NewSessionTicket are fragmented separately that the ordering becomes
relevant -- if the 0x00 is fragmented first then the peer gets the complete
fragmented message, sees the commitment message, and prepares its
authentication flight in the EAP-Response, and based on the supposed
commitment semantics would then somehow be expected to reject an
EAP-Request with NewSessionTicket as breaking the commitment.  (Assuming it
had a way to tell it was a handshake message at all, that is...)

I'd love to hear what I am missing that makes the above incorrect, and/or
that we have a way to require the NewSessionTicket and commitment message
to be part of the same fragmentation unit.

> > (A lot of my hedging in messages on this thread is because I also don't
> > really understand why the message is there.)
> > I believe I read somewhere that it stemmed from the change in who speaks
> > last in the TLS handshake, but am a bit hazy on how that implies it is
> > needed.
> 
>   I would like clarification on just what that message *means*.  If we want 
> an explicit EAP layer signal that the server saw the client cert and 
> authenticated it, then we MUST NOT send any such signal until after the 
> server has seen the client cert.  And because the EAP-Success is sent all 
> alone, we MUST then have another full round of TLS exchange, before the final 
> EAP-Success.   i.e.
> 
> 
> EAP-TLS Peer  EAP-TLS Server
> 
>  EAP-Request/
>  <  Identity
> EAP-Response/
> Identity (Privacy-Friendly)  >
>  EAP-Request/
> EAP-Type=EAP-TLS
>  <(TLS Start)
> EAP-Response/
> EAP-Type=EAP-TLS
>(TLS ClientHello) >
>  EAP-Request/
> EAP-Type=EAP-TLS
> (TLS ServerHello,
>

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

On Mon, Feb 01, 2021 at 02:52:58PM -0500, Alan DeKok wrote:
> On Feb 1, 2021, at 1:30 PM, Joseph Salowey  wrote:
> > [Joe] This could also address the early export of keys before the peer is 
> > authenticated. RFC 5216 provides a canonical way to create these IDs, but 
> > I'm not sure anyone follows it today
> 
>   FreeRADIUS does not officially expose Peer-Id or Server-Id.  But the 
> certificate subjectAltNames are available via the policy engine.  The greater 
> difficulty is *which* Id to use.
> 
>   RFC 5216 Section 5.2 says:
> 
>It is possible for more than one subjectAltName field to be present
>in a peer or server certificate in addition to an empty or non-empty
>subject distinguished name.  EAP-TLS implementations supporting
>export of the Peer-Id and Server-Id SHOULD export all the
>subjectAltName fields within Peer-Ids or Server-Ids, and SHOULD also
>export a non-empty subject distinguished name field within the Peer-
>Ids or Server-Ids.  All of the exported Peer-Ids and Server-Ids are
>considered valid.

I had missed that part of 5216 before.
While you're mostly stuck doing that sort of "all names in the cert are
deemed valid" for the TLS client certificate, since the server just asks
for *some* cert and has to handle what it gets back, that's not the normal
pattern for authenticating the server.  Consider, e.g., the RFC 6125
procedure, which takes as input to validation the name that the TLS client
was attempting to initiate communication towards.  Depending on the
application protocol that might be a DNS-ID or URI-ID or whatever, but
there's still a clear "I initiated communication towards this specific
named entity; can the server prove that it is that entity" which is very
much not "they proved possession of the private key; all names are
verified".  Even for the same server and same certificate, the answer can
be different for different names in the certificate.  (I am about to clear
a DISCUSS position on draft-ietf-quic-http for just this topic; the
historical HTTP semantics are in line with RFC 6125.  It is perhaps not
strictly required that the EAP usage do the same, but it is surprising, at
least.)

> > and it may be difficult to implement in practice due to ordering.  It might 
> > be simpler to just specify that the end entity peer and client certificates 
> > are used in the key derivation.  Most libraries provide APIs to get the raw 
> > certs.
> 
>   Yes.  We expose the certs to the policy engine, along with various fields.  
> Having the TLS exporter use more data should just be about updating some code.

I think that you get better security properties if you include the entire
certificates, but even just identities are better than nothing (provided
there is a clear unique ordering/encoding, as you note).

-Ben

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

[TLS] I-D Action: draft-ietf-tls-tlsflags-04.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

Title   : A Flags Extension for TLS 1.3
Author  : Yoav Nir
Filename: draft-ietf-tls-tlsflags-04.txt
Pages   : 9
Date: 2021-02-01

Abstract:
   A number of extensions are proposed in the TLS working group that
   carry no interesting information except the 1-bit indication that a
   certain optional feature is supported.  Such extensions take 4 octets
   each.  This document defines a flags extension that can provide such
   indications at an average marginal cost of 1 bit each.  More
   precisely, it provides as many flag extensions as needed at 4 + the
   order of the last set bit divided by 8.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-tlsflags-04
https://datatracker.ietf.org/doc/html/draft-ietf-tls-tlsflags-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tlsflags-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Joseph Salowey]

On Mon, Feb 1, 2021 at 12:04 PM Alan DeKok 
wrote:

> On Feb 1, 2021, at 3:00 PM, Joseph Salowey  wrote:
> > [Joe] What purpose is the CloseNotify serving? RFC 5216 does not require
> CloseNotify.
>
>   With TLS 1.2, the server sends TLS Finished to the client *after* it
> sees the client cert.
>
>   With TLS 1.3, the server sends TLS Finished to the client *before* it
> sees the client cert.
>
>   So the question is: when the client sees EAP-Success, has it's
> certificate been verified?  If there's no more TLS exchange server ->
> client, then malicious parties can forge an EAP-Success, and the client
> doesn't know any better.
>
>   This attack isn't possible in TLS 1.2, because the client receives the
> TLS Finished from the server, as a *positive* acknowledgement that the
> server has authenticated the client.  In addition, the TLS exporter keys
> are not available until after the server sends TLS Finished.
>
>
[Joe]   There are some cases the finished will fail (math and path
problems), but  5216 allows for a different flow which is vulnerable to an
early EAP Success:

 In the case where the server authenticates to the peer successfully,
   but the peer fails to authenticate to the server, the conversation
   will appear as follows:

   Authenticating Peer Authenticator
   --- -
   <- EAP-Request/
   Identity
   EAP-Response/
   Identity (MyID) ->
   <- EAP-Request/
   EAP-Type=EAP-TLS
   (TLS Start)
   EAP-Response/
   EAP-Type=EAP-TLS
   (TLS client_hello)->
   <- EAP-Request/
   EAP-Type=EAP-TLS
   (TLS server_hello,
 TLS certificate,
[TLS server_key_exchange,]
   TLS certificate_request,
 TLS server_hello_done)

   EAP-Response/
   EAP-Type=EAP-TLS
   (TLS certificate,
TLS client_key_exchange,
TLS certificate_verify,
TLS change_cipher_spec,
TLS finished) ->

   <- EAP-Request/
   EAP-Type=EAP-TLS
   (TLS change_cipher_spec,
   TLS finished)
   EAP-Response/
   EAP-Type=EAP-TLS ->
   <- EAP-Request
   EAP-Type=EAP-TLS
   (TLS Alert message)
   EAP-Response/
   EAP-Type=EAP-TLS ->
   <- EAP-Failure
   (User Disconnected)




>   With TLS 1.3, the exporter keys are available *before* the client cert
> has been validated.  This "fast path" helps with non-EAP protocols.  But
> makes life more difficult for EAP.
>
>
[Joe] We can use Ben's suggestion and make the exported keys depend on the
Peer and server's identities or certificates.  But if you are going to want
a protected result indication in EAP-TLS then you cannot end the early.
 5216 does not support protected result indicators, it's not clear to me if
implementations do or not.


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

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Alan DeKok]

On Feb 1, 2021, at 2:48 PM, Jorge Vergara  wrote:
> 
> There has been a lot of discussion on the ending of the handshake that I hope 
> I have parsed. Here is my perspective as an client implementor (not an 
> author):
> 
> 
> 1. I don't see a strict requirement for an authenticated signal at the end of 
> the handshake. No prior version of EAP-TLS needed this

  Prior versions *implicitly* relied on the server sending "TLS Finished" after 
the client certificate had been validated.

> and I don't necessarily see the need now. An EAP-TLS client should wait until 
> it has satisfied all of its server validation policies and completes TLS 
> before accepting a connection to the server, even if a "rogue" server starts 
> sending EAP-Success all the time. Any client which blindly connects in this 
> case is a broken client.

  We should ideally make the protocol robust to broken implementations.  RFC 
4137 was written to deal with implementations having these sort of issues in 
broken EAP state machines.

> 
> 2. Although I don't see any security benefit, such a signal *may* be 
> convenient to help EAP-TLS implementations update their state machines to 
> support TLS 1.3. For example, if an EAP-TLS state machine previously used to 
> assume that a “TLS complete” signal from its TLS library was sufficient to 
> advance to a new state where it will no longer accept TLS payload might break 
> when TLS 1.3 is used. Such a state machine would not necessarily know when to 
> advance to this state with some similar sort of signal that the server is 
> done.

  Yes.

> A different state machine which simply will always process TLS payload even 
> after a “TLS complete” signal from its TLS library may not need any updates 
> at all to work with TLS 1.3. I believe such a state machine would be able to 
> handle a NewSessionTicket after TLS completion without issues even without a 
> signal.

  True, but that's a bit of a separate issue.

> Windows currently happens to fall into the first camp, where a signal is 
> convenient. It seems to me that using close_notify is more semantically 
> correct, but has some tradeoffs.
> 
> A. In some cases, where the commitment message may be able to allow for a 
> shorter handshake, using close_notify doesn’t allow the client to send an 
> alert, which is a non-starter in my opinion.

  I agree.

> B. If we settle for an extra round trip, we can use close_notify and make 
> sure the client always has at least 1 chance to send an alert.

  Presuming that we *do* need an explicit signal, which I think is true.  If we 
do need it, then the extra round trip is unavoidable.

  Alan DeKok.

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

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Alan DeKok]

On Feb 1, 2021, at 3:00 PM, Joseph Salowey  wrote:
> [Joe] What purpose is the CloseNotify serving? RFC 5216 does not require 
> CloseNotify. 

  With TLS 1.2, the server sends TLS Finished to the client *after* it sees the 
client cert.

  With TLS 1.3, the server sends TLS Finished to the client *before* it sees 
the client cert.

  So the question is: when the client sees EAP-Success, has it's certificate 
been verified?  If there's no more TLS exchange server -> client, then 
malicious parties can forge an EAP-Success, and the client doesn't know any 
better.

  This attack isn't possible in TLS 1.2, because the client receives the TLS 
Finished from the server, as a *positive* acknowledgement that the server has 
authenticated the client.  In addition, the TLS exporter keys are not available 
until after the server sends TLS Finished.

  With TLS 1.3, the exporter keys are available *before* the client cert has 
been validated.  This "fast path" helps with non-EAP protocols.  But makes life 
more difficult for EAP.

  Alan DeKok.

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

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Joseph Salowey]

On Mon, Feb 1, 2021 at 11:55 AM Alan DeKok 
wrote:

> On Feb 1, 2021, at 2:32 PM, Joseph Salowey  wrote:
> >
> >
> >
> > On Mon, Feb 1, 2021 at 11:25 AM Alan DeKok 
> wrote:
> > On Feb 1, 2021, at 11:26 AM, Eric Rescorla  wrote:
> > > Yes, this is what I have in mind. So, maybe there's never any need for
> the server to say "I won't say anything more" after just one round trip?
> >
> >   I think so, yes.
> >
> >   That means of course EAP-TLS will always require 4.5 round trips.
> >
> > [Joe] I don't follow why this means 4.5 round trips would be required.
>
>   If the CloseNotify signal is sent by the server *after* it receives the
> client certs, then another round trip is required.  At least, according to
> Figure 1 of draft-13.
>
>   The CloseNotify can't be sent with the EAP-Success, because the
> EAP-Success can't carry data.  So the packet flow looks something like this:
>
>
[Joe] What purpose is the CloseNotify serving? RFC 5216 does not require
CloseNotify.


>EAP-TLS Peer  EAP-TLS Server
>
> EAP-Request/
> <  Identity
>EAP-Response/
>Identity (Privacy-Friendly)  >
> EAP-Request/
>EAP-Type=EAP-TLS
> <(TLS Start)
>EAP-Response/
>EAP-Type=EAP-TLS
>   (TLS ClientHello) >
> EAP-Request/
>EAP-Type=EAP-TLS
>(TLS ServerHello,
> TLS EncryptedExtensions,
>  TLS CertificateRequest,
> TLS Certificate,
>   TLS CertificateVerify,
> <---TLS Finished)
>EAP-Response/
>EAP-Type=EAP-TLS
>   (TLS Certificate,
>TLS CertificateVerify,
>TLS Finished)>
>
> EAP-Request/
>EAP-Type=EAP-TLS
> <(TLS CloseNotify)
>
>EAP-Response/
>EAP-Type=EAP-TLS
> (TLS Ack) >
> <   EAP-Success
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Alan DeKok]

On Feb 1, 2021, at 2:32 PM, Joseph Salowey  wrote:
> 
> 
> 
> On Mon, Feb 1, 2021 at 11:25 AM Alan DeKok  wrote:
> On Feb 1, 2021, at 11:26 AM, Eric Rescorla  wrote:
> > Yes, this is what I have in mind. So, maybe there's never any need for the 
> > server to say "I won't say anything more" after just one round trip?
> 
>   I think so, yes.
> 
>   That means of course EAP-TLS will always require 4.5 round trips.
> 
> [Joe] I don't follow why this means 4.5 round trips would be required.  

  If the CloseNotify signal is sent by the server *after* it receives the 
client certs, then another round trip is required.  At least, according to 
Figure 1 of draft-13.

  The CloseNotify can't be sent with the EAP-Success, because the EAP-Success 
can't carry data.  So the packet flow looks something like this:

   EAP-TLS Peer  EAP-TLS Server

EAP-Request/
<  Identity
   EAP-Response/
   Identity (Privacy-Friendly)  >
EAP-Request/
   EAP-Type=EAP-TLS
<(TLS Start)
   EAP-Response/
   EAP-Type=EAP-TLS
  (TLS ClientHello) >
EAP-Request/
   EAP-Type=EAP-TLS
   (TLS ServerHello,
TLS EncryptedExtensions,
 TLS CertificateRequest,
TLS Certificate,
  TLS CertificateVerify,
<---TLS Finished)
   EAP-Response/
   EAP-Type=EAP-TLS
  (TLS Certificate,
   TLS CertificateVerify,
   TLS Finished)>

EAP-Request/
   EAP-Type=EAP-TLS
<(TLS CloseNotify)

   EAP-Response/
   EAP-Type=EAP-TLS
(TLS Ack) >
<   EAP-Success
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Alan DeKok]

On Feb 1, 2021, at 1:30 PM, Joseph Salowey  wrote:
> [Joe] This could also address the early export of keys before the peer is 
> authenticated. RFC 5216 provides a canonical way to create these IDs, but I'm 
> not sure anyone follows it today

  FreeRADIUS does not officially expose Peer-Id or Server-Id.  But the 
certificate subjectAltNames are available via the policy engine.  The greater 
difficulty is *which* Id to use.

  RFC 5216 Section 5.2 says:

   It is possible for more than one subjectAltName field to be present
   in a peer or server certificate in addition to an empty or non-empty
   subject distinguished name.  EAP-TLS implementations supporting
   export of the Peer-Id and Server-Id SHOULD export all the
   subjectAltName fields within Peer-Ids or Server-Ids, and SHOULD also
   export a non-empty subject distinguished name field within the Peer-
   Ids or Server-Ids.  All of the exported Peer-Ids and Server-Ids are
   considered valid.

> and it may be difficult to implement in practice due to ordering.  It might 
> be simpler to just specify that the end entity peer and client certificates 
> are used in the key derivation.  Most libraries provide APIs to get the raw 
> certs.

  Yes.  We expose the certs to the policy engine, along with various fields.  
Having the TLS exporter use more data should just be about updating some code.

  Alan DeKok.

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

Re: [TLS] ALPS and TLS 1.3 half-RTT data

[David Benjamin]

On Mon, Feb 1, 2021 at 8:46 AM Cory Benfield  wrote:

> On Fri, 29 Jan 2021 at 23:38, David Benjamin 
> wrote:
> > To clarify, are you unconvinced that ALPS is easier than leaving H2
> alone, or that ALPS is easier than solving this problem with half-RTT? The
> document’s aim is the latter. Your comment in Martin’s thread reads to me
> like you agree with this. Am I interpreting that correctly? (I think
> draft-thomson-httpbis-h2-0rtt roughly corresponds to Section 2.3 of my
> document. Something like it would be necessary, but not sufficient, to
> solve this with half-RTT.)
> >
> >
> > As to leaving H2 alone, doing nothing is indeed generally easier than
> doing something. But this is perhaps not a useful criteria. :-) The
> question is what’s the benefit of solving the problem. My interest is in
> the privacy benefits of rethinking content negotiation. Victor has use
> cases around WebTransport. The document cites some other uses.
>
> I am unconvinced that ALPS is easier than leaving H2 alone _and_ that
> I've not been sold on the criticality of adding content negotiation of
> this form. You say you're interested in the privacy benefits, but the
> draft doesn't state what those are expected to be, or what they're
> being compared to. I assume they're being compared to 0.5RTT data. If
> that's true, then sure, I can see the privacy benefits. However,
> that's not the status quo, and so not necessarily a meaningful
> comparison point.
>
> The document notes a single rationale:
>
> >   One of the properties of the
> >   mechanism as defined by both of those protocols is that the parties
> >   start out without having access to the entirety of the peer's
> >   settings.  This means that they have to initially operate using the
> >   default settings, and after receiving the SETTINGS frame, they have
> >   to find a way to transition from the default to the exchanged
> >   settings.
>
> I agree that this statement is an accurate representation of the state
> of things today. I also agree that having access to the settings
> before application traffic is negotiated will enable some use-cases
> that are otherwise tricky. But this is still not a concrete problem
> statement, merely a statement of hypothetical utility.
>

Ah, sorry, I think I was unclear here. The problem with trying to divide
things up into abstractions is that it's very easy to mix up talking about
the abstractions on their own vs. the broader context. :-) Let me try that
again:

ALPS aims to fix the ordering of H[23] SETTINGS relative to HTTP requests.
In evaluating this, I think it's worth separating out:
1. What are the benefits to solving this problem, however we solve it?
2. Assuming we want to solve this problem, what is the best way to do it?
ALPS? Half-RTT? Something else?

And then the question is whether (1) justifies the best solution we can
find for (2). The alps-half-rtt document mostly discussed (2), while my
reference to privacy properties was about (1). (I don't think ALPS and
half-RTT have immediate differences in privacy properties. Though I think
there may be some indirect ones w.r.t. how robustly we can communicate the
authenticated vs. unauthenticated distinction across TLS and the
application protocol.)

To more concretely talking about (1):

My interest is in Client Hint Reliability. We're looking to shift some
information away from being always sent in client requests, notably in the
User-Agent header, to only being sent when requested. That'll help with
detecting and mitigating fingerprinting. Something like ALPS will help
smooth over the perf costs of this.
https://tools.ietf.org/html/draft-davidben-http-client-hint-reliability-02
https://github.com/bslassey/privacy-budget

Victor touched on some other use cases here. I'll let him elaborate on what
else he has in mind.
https://lists.w3.org/Archives/Public/ietf-http-wg/2020JulSep/0003.html

Finally, this idea originally came up with QUIC's integration between
SETTINGS and NewSessionTicket (roughly draft-thomson-httpbis-h2-0rtt, plus
some additional QUIC-specific ordering headers). We largely resolved those
but, IMO, unsatisfyingly. (It requires non-trivial h3/TLS integration, both
in 0-RTT acceptance criteria and when to process NewSessionTickets.) There
was some discussion about an alternate ALPS-looking approach (only in the
server-to-client direction), but the WG wanted it to work in both
directions, so... here we are. :-)
https://github.com/quicwg/base-drafts/issues/3086#issuecomment-543373506


> > Systems and thus their problems span components. The question is how
> best to split a solution across those components. The aim with ALPS is to
> minimize coupling while still getting settings for the first client write.
> We can build something piecemeal with half-RTT, ticket state, and early
> data callbacks. Or we can abstract a notion of “protocol settings”,
> configured and surfaced at well-defined points. I prefer the latter.
>
> Systems do span components, but 

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Jorge Vergara]

There has been a lot of discussion on the ending of the handshake that I hope I 
have parsed. Here is my perspective as an client implementor (not an author):



1. I don't see a strict requirement for an authenticated signal at the end of 
the handshake. No prior version of EAP-TLS needed this and I don't necessarily 
see the need now. An EAP-TLS client should wait until it has satisfied all of 
its server validation policies and completes TLS before accepting a connection 
to the server, even if a "rogue" server starts sending EAP-Success all the 
time. Any client which blindly connects in this case is a broken client.



2. Although I don't see any security benefit, such a signal *may* be convenient 
to help EAP-TLS implementations update their state machines to support TLS 1.3. 
For example, if an EAP-TLS state machine previously used to assume that a "TLS 
complete" signal from its TLS library was sufficient to advance to a new state 
where it will no longer accept TLS payload might break when TLS 1.3 is used. 
Such a state machine would not necessarily know when to advance to this state 
with some similar sort of signal that the server is done.



A different state machine which simply will always process TLS payload even 
after a "TLS complete" signal from its TLS library may not need any updates at 
all to work with TLS 1.3. I believe such a state machine would be able to 
handle a NewSessionTicket after TLS completion without issues even without a 
signal.



Windows currently happens to fall into the first camp, where a signal is 
convenient. It seems to me that using close_notify is more semantically 
correct, but has some tradeoffs.



A. In some cases, where the commitment message may be able to allow for a 
shorter handshake, using close_notify doesn't allow the client to send an 
alert, which is a non-starter in my opinion.

B. If we settle for an extra round trip, we can use close_notify and make sure 
the client always has at least 1 chance to send an alert.



This seems to me to be roughly where we started the discussion. Perhaps I have 
some of the theoretical details regarding the authenticated end signal 
incorrect as my perception is definitely colored by being mainly a client 
implementor. I happen to prefer the draft-13 commitment message because it 
seems to allow one less round trip in some cases. I'm happy to see discussion 
occurring either way and hope my perspective as an implementor is useful in 
driving toward a resolution.



Jorge Vergara


From: Emu  On Behalf Of Joseph Salowey
Sent: Monday, February 1, 2021 11:32 AM
To: Alan DeKok 
Cc:  ; EMU WG ; Benjamin Kaduk 

Subject: Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on 
draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)



On Mon, Feb 1, 2021 at 11:25 AM Alan DeKok 
mailto:al...@deployingradius.com>> wrote:
On Feb 1, 2021, at 11:26 AM, Eric Rescorla 
mailto:e...@rtfm.com>> wrote:
> Yes, this is what I have in mind. So, maybe there's never any need for the 
> server to say "I won't say anything more" after just one round trip?

  I think so, yes.

  That means of course EAP-TLS will always require 4.5 round trips.

[Joe] I don't follow why this means 4.5 round trips would be required.

  Alan DeKok.

___
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] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Joseph Salowey]

On Mon, Feb 1, 2021 at 11:25 AM Alan DeKok 
wrote:

> On Feb 1, 2021, at 11:26 AM, Eric Rescorla  wrote:
> > Yes, this is what I have in mind. So, maybe there's never any need for
> the server to say "I won't say anything more" after just one round trip?
>
>   I think so, yes.
>
>   That means of course EAP-TLS will always require 4.5 round trips.
>
>
[Joe] I don't follow why this means 4.5 round trips would be required.


>   Alan DeKok.
>
> ___
> 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] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Alan DeKok]

On Feb 1, 2021, at 11:26 AM, Eric Rescorla  wrote:
> Yes, this is what I have in mind. So, maybe there's never any need for the 
> server to say "I won't say anything more" after just one round trip?

  I think so, yes.

  That means of course EAP-TLS will always require 4.5 round trips.

  Alan DeKok.

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

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Joseph Salowey]

On Mon, Feb 1, 2021 at 9:12 AM Benjamin Kaduk  wrote:

> Hi Alan,
>
> I'll second the thanks for putting this together; I think it covers the
> important open points.
>
> I did belatedly remember one more thing that is perhaps not critical, but
> would also be good to get an answer for:
>
> On Fri, Jan 29, 2021 at 03:00:51PM -0500, Alan DeKok wrote:
> [...]
> >
> > DISCUSS: other than word-smithing the above points, are there serious
> objections to the behaviour documented in -13?  i.e. does the IETF want to
> recommend that EAP-TLS alpha testing begins *now*, or should it wait until
> 2022?
>
> I think that an exchange between Martin and Mohit raised the question of
> whether the EAP server-id and peer-id would be available for use in the
> 'context' argument of the TLS Exporter, as that would help strengthen the
> binding between keys and the authentication exchange.
> I do recall a mention that WolfSSL doesn't support a context argument for
> the exporter, but I don't know how prohibitive that limitation would be in
> practice.
>
>
[Joe] This could also address the early export of keys before the peer is
authenticated. RFC 5216 provides a canonical way to create these IDs, but
I'm not sure anyone follows it today and it may be difficult to implement
in practice due to ordering.  It might be simpler to just specify that the
end entity peer and client certificates are used in the key derivation.
Most libraries provide APIs to get the raw certs.
It looks like the WolfSSL API that Mohit linked is specifically for RFC5216
EAP keys and not a general exporter API.  I'm not sure if they have a
general exporter API.


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

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

Hi Alan,

I'll second the thanks for putting this together; I think it covers the
important open points.

I did belatedly remember one more thing that is perhaps not critical, but
would also be good to get an answer for:

On Fri, Jan 29, 2021 at 03:00:51PM -0500, Alan DeKok wrote:
[...]
> 
> DISCUSS: other than word-smithing the above points, are there serious 
> objections to the behaviour documented in -13?  i.e. does the IETF want to 
> recommend that EAP-TLS alpha testing begins *now*, or should it wait until 
> 2022?

I think that an exchange between Martin and Mohit raised the question of
whether the EAP server-id and peer-id would be available for use in the
'context' argument of the TLS Exporter, as that would help strengthen the
binding between keys and the authentication exchange.
I do recall a mention that WolfSSL doesn't support a context argument for
the exporter, but I don't know how prohibitive that limitation would be in
practice.

-Ben

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

[TLS] Protocol Action: 'TLS Ticket Requests' to Proposed Standard (draft-ietf-tls-ticketrequests-07.txt)

[The IESG]

The IESG has approved the following document:
- 'TLS Ticket Requests'
  (draft-ietf-tls-ticketrequests-07.txt) as Proposed Standard

This document is the product of the Transport Layer Security Working Group.

The IESG contact persons are Benjamin Kaduk and Roman Danyliw.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/




Technical Summary

This document defines a TLS extension that clients can use to inform servers
about the desired number of tickets to generate, in order to reduce ticket waste
while simultaneously letting clients prepare for future connection attempts.

Working Group Summary

The draft had a fairly quiet existence until the -02 version, which was 
also the version where the authors requested the chairs request WGLC.
The WGLC and two issue-specific consensus calls that followed were all
fairly contentious.  The WGLC and the two issue-specific consensus calls
resulted in changes to the draft: the count field was renamed
new_session_count, a new counter called resumption_count was added, and 
text was added to address racing pre-conditions.  The addition of the
second counter acknowledged that resumption is different and can
tolerate the complexity of the additional counter. What was not added
was text to address ticket reuse use cases; RFC 8446 indicates "clients
SHOULD NOT reuse a ticket for multiple connections". One of the
issue-specific consensus calls about this was about this point and there
was no consensus to add text to address this use case.

The consensus should probably be characterized as rough. This is because
it seems that that the same people that supported adopting the draft
support publishing the mechanism, but there are differences in how far
participants believe the mechanism should go in supporting ticket reuse.

Document Quality

Due to the controversial nature of the discussion of ticket reuse,
essentially all the text in this document received careful review from
many WG participants.  It should be of high quality, though to my
knowledge implementors wanted to wait until the controversy was
settled (i.e., by publication) before implementing.

Personnel

Sean Turner is the Shepherd.
Ben Kaduk is the Area Director.



RFC Editor Note

  Please ensure that the current (RFC 8174) form of BCP 14 boilerplate is used.

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

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Eric Rescorla]

On Mon, Feb 1, 2021 at 8:22 AM Alan DeKok  wrote:

> On Feb 1, 2021, at 11:09 AM, Eric Rescorla  wrote:
> > That's not what I'm proposing. I'm only talking about the case where the
> server says this after flight (2).
>
>   OK, my misreading of the text.
>
> > Right. But close_notify is the message that more matches the TLS
> semantics.
>
>   I agree.
>
> > Ignoring the protocol mechanics, let's just talk about what signals you
> think the client ought to want to receive. The two I am aware of are:
> >
> > 1. From the server's perspective, the TLS handshake is complete.
> > 2. The server will not be sending any more handshake messages to the
> client.
> >
> > When client authentication is being used, then for obvious reasons (1)
> cannot be delivered prior to the server receiving and processing the
> client's certificate. Agreed?
>
>   Yes.
>
> > Indeed, this seems like a problem with the flow shown in Figure 1,
> because the server sends Commitment prior to reading the client's cert.
>
>   Yes.
>
> > ISTM that the relevant question is when one might want to receive (2).
> In particular, when would the client want to learn that the server will not
> send any more handshake messages when the client has second flight
> handshake messages still outstanding? Can you explain to me how this is
> useful?
>
>   I'm just trying to summarize the discussion so far, and get
> clarification on exactly what we're trying to do. So take what I say with a
> grain of salt... I didn't write the text in the current draft.
>
>   The main issue I can see where (2) might be useful is to deal with TLS
> 1.3's separation of "TLS finished" from other handshake messages.  If the
> SessionTicket message comes *after* "TLS finished", then it might be in a
> separate EAP packet.  The client doesn't know that there's an additional
> handshake until it receives that message.
>
>   So an explicit CloseNotify sent by the server *after* receiving the
> client certificate would seem useful.  It's an authenticated message saying
> "yes, I agree we're done".
>
>   If the client cert has issues, the server can send TLS alerts *before*
> the CloseNotify.  So the client has to either wait for those, OR an
> explicit CloseNotify, to see if it's (a) rejected, or (b) authenticated
>

Yes, this is what I have in mind. So, maybe there's never any need for the
server to say "I won't say anything more" after just one round trip?

-Ekr

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

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Alan DeKok]

On Feb 1, 2021, at 11:09 AM, Eric Rescorla  wrote:
> That's not what I'm proposing. I'm only talking about the case where the 
> server says this after flight (2).

  OK, my misreading of the text.

> Right. But close_notify is the message that more matches the TLS semantics.

  I agree.

> Ignoring the protocol mechanics, let's just talk about what signals you think 
> the client ought to want to receive. The two I am aware of are:
> 
> 1. From the server's perspective, the TLS handshake is complete.
> 2. The server will not be sending any more handshake messages to the client.
> 
> When client authentication is being used, then for obvious reasons (1) cannot 
> be delivered prior to the server receiving and processing the client's 
> certificate. Agreed?

  Yes.

> Indeed, this seems like a problem with the flow shown in Figure 1, because 
> the server sends Commitment prior to reading the client's cert.

  Yes.

> ISTM that the relevant question is when one might want to receive (2).  In 
> particular, when would the client want to learn that the server will not send 
> any more handshake messages when the client has second flight handshake 
> messages still outstanding? Can you explain to me how this is useful?

  I'm just trying to summarize the discussion so far, and get clarification on 
exactly what we're trying to do. So take what I say with a grain of salt... I 
didn't write the text in the current draft.

  The main issue I can see where (2) might be useful is to deal with TLS 1.3's 
separation of "TLS finished" from other handshake messages.  If the 
SessionTicket message comes *after* "TLS finished", then it might be in a 
separate EAP packet.  The client doesn't know that there's an additional 
handshake until it receives that message.

  So an explicit CloseNotify sent by the server *after* receiving the client 
certificate would seem useful.  It's an authenticated message saying "yes, I 
agree we're done".

  If the client cert has issues, the server can send TLS alerts *before* the 
CloseNotify.  So the client has to either wait for those, OR an explicit 
CloseNotify, to see if it's (a) rejected, or (b) authenticated

  Alan DeKok.

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

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Eric Rescorla]

On Mon, Feb 1, 2021 at 7:42 AM Alan DeKok  wrote:

> On Feb 1, 2021, at 9:55 AM, Eric Rescorla  wrote:
> > Let's take the second case first. If the server is sending (or
> > potentially sending) post-handshake messages after the client's second
> > flight (e.g., after reading its certificate), then it can easily send
> > a close_notify after sending all of them. This will appear in the same
> > flight as the commitment message would have (because you can't send it
> > before the post-handshake messages) and avoid the need for an extra
> > round trip.
>
>   That use of CloseNotify would be before the server receives the client
> certificates.  It prevents the server from sending TLS alerts for
> certificate errors (expired, unknown CA, etc).  That would be an
> unmitigated disaster for deployments.
>

That's not what I'm proposing. I'm only talking about the case where the
server says this after flight (2).


  The CloseNotify *could* be sent after the server receives the client
> certs.  But that still means another full round of EAP, before the final
> EAP-Success.  So from that view, there's no difference between CloseNotify
> and an explicit commitment message.
>

Right. But close_notify is the message that more matches the TLS semantics.


> > The first case, where the commitment message is sent in 0.5-RTT,
> > is the interesting one. However, the server has no more information
> > after sending SFIN than it does sending EE, so I believe that the
> > easiest way to deal with this is with a TLS extension that says
> > "I do not send any post-handshake messages". This would still
> > leave the server free to send any relevant alerts in response to
> > the client's second flight.
>
>   Except that if the server likes the client cert, Figure 1 of draft-13
> shows the next packet is EAP-Success.  So the client has no *authenticated*
> way of telling that it has been authenticated.  Any party to the
> conversation could send a blank EAP-Success (which is 4 bytes of
> unauthenticated data).  And thus break EAP-TLS.
>

I fear we are talking past each other.

Ignoring the protocol mechanics, let's just talk about what signals you
think the client ought to want to receive. The two I am aware of are:

1. From the server's perspective, the TLS handshake is complete.
2. The server will not be sending any more handshake messages to the client.

When client authentication is being used, then for obvious reasons (1)
cannot be delivered prior to the server receiving and processing the
client's certificate. Agreed? Indeed, this seems like a problem with the
flow shown in Figure 1, because the server sends Commitment prior to
reading the client's cert.

ISTM that the relevant question is when one might want to receive (2).  In
particular, when would the client want to learn that the server will not
send any more handshake messages when the client has second flight
handshake messages still outstanding? Can you explain to me how this is
useful?

-Ekr


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

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Alan DeKok]

On Feb 1, 2021, at 9:55 AM, Eric Rescorla  wrote:
> Let's take the second case first. If the server is sending (or
> potentially sending) post-handshake messages after the client's second
> flight (e.g., after reading its certificate), then it can easily send
> a close_notify after sending all of them. This will appear in the same
> flight as the commitment message would have (because you can't send it
> before the post-handshake messages) and avoid the need for an extra
> round trip.

  That use of CloseNotify would be before the server receives the client 
certificates.  It prevents the server from sending TLS alerts for certificate 
errors (expired, unknown CA, etc).  That would be an unmitigated disaster for 
deployments.

  The CloseNotify *could* be sent after the server receives the client certs.  
But that still means another full round of EAP, before the final EAP-Success.  
So from that view, there's no difference between CloseNotify and an explicit 
commitment message.

> The first case, where the commitment message is sent in 0.5-RTT,
> is the interesting one. However, the server has no more information
> after sending SFIN than it does sending EE, so I believe that the
> easiest way to deal with this is with a TLS extension that says
> "I do not send any post-handshake messages". This would still
> leave the server free to send any relevant alerts in response to
> the client's second flight.

  Except that if the server likes the client cert, Figure 1 of draft-13 shows 
the next packet is EAP-Success.  So the client has no *authenticated* way of 
telling that it has been authenticated.  Any party to the conversation could 
send a blank EAP-Success (which is 4 bytes of unauthenticated data).  And thus 
break EAP-TLS.

  Alan DeKok.

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

Re: [TLS] I-D Action: draft-ietf-tls-subcerts-10.txt

[Russ Housley]

Works for me.

> On Jan 31, 2021, at 11:58 PM, Sean Turner  wrote:
> 
> Do you think this would be clearer:
> 
>  The maximum validity period is set to 7 days unless
>  an application profile standard specifies a shorter
>  period.
> 
> spt
> 
>> On Jan 25, 2021, at 11:14, Russ Housley  wrote:
>> 
>> I have reviewed the recent update, and I notice one inconsistency.
>> 
>> Section 2 says:
>> 
>>  In the absence of an application profile standard
>>  specifying otherwise, the maximum validity period is set to 7 days.
>> 
>> Section 4.1.3 says:
>> 
>>  1.  Validate that DelegatedCredential.cred.valid_time is no more than
>>  7 days.
>> 
>> I think that Section 2 is trying to say that an application profile can make 
>> it even shorter than 7 days, but on my first reading I got the opposite.
>> 
>> Russ
>> 
>> 
>>> On Jan 24, 2021, at 6:03 PM, internet-dra...@ietf.org wrote:
>>> 
>>> 
>>> A New Internet-Draft is available from the on-line Internet-Drafts 
>>> directories.
>>> This draft is a work item of the Transport Layer Security WG of the IETF.
>>> 
>>>  Title   : Delegated Credentials for TLS
>>>  Authors : Richard Barnes
>>>Subodh Iyengar
>>>Nick Sullivan
>>>Eric Rescorla
>>> Filename: draft-ietf-tls-subcerts-10.txt
>>> Pages   : 19
>>> Date: 2021-01-24
>>> 
>>> Abstract:
>>> The organizational separation between the operator of a TLS endpoint
>>> and the certification authority can create limitations.  For example,
>>> the lifetime of certificates, how they may be used, and the
>>> algorithms they support are ultimately determined by the
>>> certification authority.  This document describes a mechanism by
>>> which operators may delegate their own credentials for use in TLS,
>>> without breaking compatibility with peers that do not support this
>>> specification.
>>> 
>>> 
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/
>>> 
>>> There are also htmlized versions available at:
>>> https://tools.ietf.org/html/draft-ietf-tls-subcerts-10
>>> https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-10
>>> 
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-10
>>> 
>>> 
>>> Please note that it may take a couple of minutes from the time of submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>> 
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>> 
>>> 
>>> ___
>>> 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 mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Salz, Rich]

>Asking as the author of a TLS library that has always done this, why would 
> you
stop immediately after the Finished and leave metadata messages sitting 
unread
in the input stream?  Was it just some arbitrary implementation decision, or
is there a technical reason for it?

The mistaken belief that applications really wanted to control all the knobs 
and flow of control of the protocol.


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

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Eric Rescorla]

On Fri, Jan 29, 2021 at 12:02 PM Alan DeKok 
wrote:

>   This is a new message to summarize history, requirements, etc. for
> EAP-TLS and TLS 1.3.  The focus here is the requirements for EAP-TLS, and
> how the 0x00 commitment message versus CloseNotify meets those.  I'll
> ignore the exporter changes here, as those are less controversial.
>
>   The original proposal in the EAP-TLS draft was to send a zero-length
> application data message in order to signal that no more post-handshake
> messages were needed.  From the -05 version:
>
>When an EAP server has sent its last handshake message (Finished or a
>Post-Handshake), it commits to not sending any more handshake
>messages by appending an empty application data record (i.e. a TLS
>record with TLSPlaintext.type = application_data and
>TLSPlaintext.length = 0) to the last handshake record.  After sending
>an empty application data record, the EAP server may only send an
>EAP-Success, an EAP-Failure, or an EAP-Request with a TLS Alert
>Message.
>
>   However, the OpenSSL APIs (among others) do not allow for sending zero
> octets of application data.  The proposal was then changed to send a 0x00
> octet.
>
>  There was discussion that CloseNotify could achieve the same goals.  But
> CloseNotify requires an additional round trip.  There are strong opinions
> that additional round trips are bad.
>
>   In addition, CloseNotify prevents the TLS layer from sending a TLS Fatal
> Alert:  https://www.mail-archive.com/emu@ietf.org/msg03092.html


I agree that extra round trips are bad, I'd like to take a step back
here and think about what this message is trying to do. Here's
the relevant text:

   TLS 1.3 [RFC8446] introduces Post-Handshake messages.  These Post-
   Handshake messages use the handshake content type and can be sent
   after the main handshake.  One such Post-Handshake message is
   NewSessionTicket.  The NewSessionTicket can be used for resumption.
   After sending TLS Finished, the EAP-TLS server may send any number of
   Post-Handshake messages in separate EAP-Requests.

The relevant question is when the server knows what post-handshake
messages it will send. There are two points at which the server might
wish to send post-handshake messages:

1. After the server's first flight.
2. After the client's second flight.

Let's take the second case first. If the server is sending (or
potentially sending) post-handshake messages after the client's second
flight (e.g., after reading its certificate), then it can easily send
a close_notify after sending all of them. This will appear in the same
flight as the commitment message would have (because you can't send it
before the post-handshake messages) and avoid the need for an extra
round trip.

The first case, where the commitment message is sent in 0.5-RTT,
is the interesting one. However, the server has no more information
after sending SFIN than it does sending EE, so I believe that the
easiest way to deal with this is with a TLS extension that says
"I do not send any post-handshake messages". This would still
leave the server free to send any relevant alerts in response to
the client's second flight.

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

Re: [TLS] ALPS and TLS 1.3 half-RTT data

[Cory Benfield]

Oh, and I should say this out loud: my attitude to ALPS has softened
in the past two months or so. I definitely don't want my comments to
be perceived as being in opposition to the adoption of new work by
this WG: I just want to flesh out exactly what problems we're trying
to solve, so that we can accurately assess whether ALPS is the right
solution for them.

ALPS is a good solution to some real problems. I want to make sure I
understand what problems it's solving in H2, so I can try to judge
whether I think it's a good solution for _those_ problems.

On Mon, 1 Feb 2021 at 13:46, Cory Benfield  wrote:
>
> On Fri, 29 Jan 2021 at 23:38, David Benjamin  wrote:
> >
> > Hi all,
> >
> >
> > Thanks all for the feedback. I’ve tried to address it below, but there's a 
> > lot of text, so please let me know if I’ve missed or misunderstood any of 
> > your points.
> >
> >
> > Cory commented on SETTINGS_[HQ]PACK_ENABLE_STATIC_TABLES in 
> > draft-vvv-httpbis-alps-00. I agree that is odd. We’ve uploaded a draft-01 
> > that drops it.
> >
> >
> > Cory also wrote:
> >
> > > I think the document does a good job laying out the difficulties with
> >
> > > half-RTT data, but it didn't convince me that ALPS is easier for H2.
> >
> >
> > To clarify, are you unconvinced that ALPS is easier than leaving H2 alone, 
> > or that ALPS is easier than solving this problem with half-RTT? The 
> > document’s aim is the latter. Your comment in Martin’s thread reads to me 
> > like you agree with this. Am I interpreting that correctly? (I think 
> > draft-thomson-httpbis-h2-0rtt roughly corresponds to Section 2.3 of my 
> > document. Something like it would be necessary, but not sufficient, to 
> > solve this with half-RTT.)
> >
> >
> > As to leaving H2 alone, doing nothing is indeed generally easier than doing 
> > something. But this is perhaps not a useful criteria. :-) The question is 
> > what’s the benefit of solving the problem. My interest is in the privacy 
> > benefits of rethinking content negotiation. Victor has use cases around 
> > WebTransport. The document cites some other uses.
>
> I am unconvinced that ALPS is easier than leaving H2 alone _and_ that
> I've not been sold on the criticality of adding content negotiation of
> this form. You say you're interested in the privacy benefits, but the
> draft doesn't state what those are expected to be, or what they're
> being compared to. I assume they're being compared to 0.5RTT data. If
> that's true, then sure, I can see the privacy benefits. However,
> that's not the status quo, and so not necessarily a meaningful
> comparison point.
>
> The document notes a single rationale:
>
> >   One of the properties of the
> >   mechanism as defined by both of those protocols is that the parties
> >   start out without having access to the entirety of the peer's
> >   settings.  This means that they have to initially operate using the
> >   default settings, and after receiving the SETTINGS frame, they have
> >   to find a way to transition from the default to the exchanged
> >   settings.
>
> I agree that this statement is an accurate representation of the state
> of things today. I also agree that having access to the settings
> before application traffic is negotiated will enable some use-cases
> that are otherwise tricky. But this is still not a concrete problem
> statement, merely a statement of hypothetical utility.
>
>
> > > My biggest concerns are around the need to tightly couple the TLS and
> >
> > > application layer stacks.
> >
> >
> > I agree this adds a non-I/O TLS interaction, but adding interactions isn’t 
> > new. Many HTTP mechanisms touch TLS:
> >
> > RFC8473 uses TLS exporters.
> > RFC5929 specifies various TLS channel bindings interfaces for 
> > authentication protocols.
> > RFC8470 integrates with the 0-RTT/1-RTT transition point.
> > ALPN itself uses TLS to select variations on HTTP.
> > Section 9.2.2 of RFC7540 specifies cipher suites for HTTP/2.
> > HTTP/2 cross-name pooling and HTTP’s general notion of authority are tied 
> > to the TLS certificate.
> > Applications using client certificates care about the relation between 
> > TLS-level authentication and HTTP messages. The web even has a notion of 
> > “uncredentialed” HTTP fetches which shouldn’t send client certificates.
> > Secondary certificates use TLS exported authenticators.
> >
> > Systems and thus their problems span components. The question is how best 
> > to split a solution across those components. The aim with ALPS is to 
> > minimize coupling while still getting settings for the first client write. 
> > We can build something piecemeal with half-RTT, ticket state, and early 
> > data callbacks. Or we can abstract a notion of “protocol settings”, 
> > configured and surfaced at well-defined points. I prefer the latter.
>
> Systems do span components, but reducing coupling between those
> systems is good. I agree that glomming things together out of an
> arbitrary collection of poorly 

Re: [TLS] ALPS and TLS 1.3 half-RTT data

[Cory Benfield]

On Fri, 29 Jan 2021 at 23:38, David Benjamin  wrote:
>
> Hi all,
>
>
> Thanks all for the feedback. I’ve tried to address it below, but there's a 
> lot of text, so please let me know if I’ve missed or misunderstood any of 
> your points.
>
>
> Cory commented on SETTINGS_[HQ]PACK_ENABLE_STATIC_TABLES in 
> draft-vvv-httpbis-alps-00. I agree that is odd. We’ve uploaded a draft-01 
> that drops it.
>
>
> Cory also wrote:
>
> > I think the document does a good job laying out the difficulties with
>
> > half-RTT data, but it didn't convince me that ALPS is easier for H2.
>
>
> To clarify, are you unconvinced that ALPS is easier than leaving H2 alone, or 
> that ALPS is easier than solving this problem with half-RTT? The document’s 
> aim is the latter. Your comment in Martin’s thread reads to me like you agree 
> with this. Am I interpreting that correctly? (I think 
> draft-thomson-httpbis-h2-0rtt roughly corresponds to Section 2.3 of my 
> document. Something like it would be necessary, but not sufficient, to solve 
> this with half-RTT.)
>
>
> As to leaving H2 alone, doing nothing is indeed generally easier than doing 
> something. But this is perhaps not a useful criteria. :-) The question is 
> what’s the benefit of solving the problem. My interest is in the privacy 
> benefits of rethinking content negotiation. Victor has use cases around 
> WebTransport. The document cites some other uses.

I am unconvinced that ALPS is easier than leaving H2 alone _and_ that
I've not been sold on the criticality of adding content negotiation of
this form. You say you're interested in the privacy benefits, but the
draft doesn't state what those are expected to be, or what they're
being compared to. I assume they're being compared to 0.5RTT data. If
that's true, then sure, I can see the privacy benefits. However,
that's not the status quo, and so not necessarily a meaningful
comparison point.

The document notes a single rationale:

>   One of the properties of the
>   mechanism as defined by both of those protocols is that the parties
>   start out without having access to the entirety of the peer's
>   settings.  This means that they have to initially operate using the
>   default settings, and after receiving the SETTINGS frame, they have
>   to find a way to transition from the default to the exchanged
>   settings.

I agree that this statement is an accurate representation of the state
of things today. I also agree that having access to the settings
before application traffic is negotiated will enable some use-cases
that are otherwise tricky. But this is still not a concrete problem
statement, merely a statement of hypothetical utility.


> > My biggest concerns are around the need to tightly couple the TLS and
>
> > application layer stacks.
>
>
> I agree this adds a non-I/O TLS interaction, but adding interactions isn’t 
> new. Many HTTP mechanisms touch TLS:
>
> RFC8473 uses TLS exporters.
> RFC5929 specifies various TLS channel bindings interfaces for authentication 
> protocols.
> RFC8470 integrates with the 0-RTT/1-RTT transition point.
> ALPN itself uses TLS to select variations on HTTP.
> Section 9.2.2 of RFC7540 specifies cipher suites for HTTP/2.
> HTTP/2 cross-name pooling and HTTP’s general notion of authority are tied to 
> the TLS certificate.
> Applications using client certificates care about the relation between 
> TLS-level authentication and HTTP messages. The web even has a notion of 
> “uncredentialed” HTTP fetches which shouldn’t send client certificates.
> Secondary certificates use TLS exported authenticators.
>
> Systems and thus their problems span components. The question is how best to 
> split a solution across those components. The aim with ALPS is to minimize 
> coupling while still getting settings for the first client write. We can 
> build something piecemeal with half-RTT, ticket state, and early data 
> callbacks. Or we can abstract a notion of “protocol settings”, configured and 
> surfaced at well-defined points. I prefer the latter.

Systems do span components, but reducing coupling between those
systems is good. I agree that glomming things together out of an
arbitrary collection of poorly supported protocol components is not a
better solution than having a single extension point. I am pressing
back on the idea that this problem requires coupling these systems at
all. Well-designed, simple, extensible coupling is better than poorly
designed coupling, but worse than no coupling at all.

> As to the complexity, I think you may be overestimating it. It sounds like 
> your model has three components: TLS, HTTP/2, and some ALPN dispatcher. And 
> your concern is complexity in HTTP/2. Is that right? ALPS should slot next to 
> ALPN processing at the same points. For example:
>
> The dispatcher already must know which ALPN protocols are supported and how 
> to instantiate them.
> Extend it so protocols can optionally be ALPS-aware. An ALPS-aware protocol 
> has a settings parameter 

Re: [TLS] I-D Action: draft-ietf-tls-subcerts-10.txt

[Daniel Migault]

Hi,

It is unclear to me if the current version is expected to address the
comments received during the WGLCs or if further versions are expected.
Just to clarify the current version does not address my comments concerning
the related work section [1].

Yours,
Daniel

[1] https://mailarchive.ietf.org/arch/msg/tls/B7qc2sPH_d9Tfr-W7vnf24jiGds/

On Sun, Jan 31, 2021 at 11:59 PM Sean Turner  wrote:

> Do you think this would be clearer:
>
>   The maximum validity period is set to 7 days unless
>   an application profile standard specifies a shorter
>   period.
>
> spt
>
> > On Jan 25, 2021, at 11:14, Russ Housley  wrote:
> >
> > I have reviewed the recent update, and I notice one inconsistency.
> >
> > Section 2 says:
> >
> >   In the absence of an application profile standard
> >   specifying otherwise, the maximum validity period is set to 7 days.
> >
> > Section 4.1.3 says:
> >
> >   1.  Validate that DelegatedCredential.cred.valid_time is no more than
> >   7 days.
> >
> > I think that Section 2 is trying to say that an application profile can
> make it even shorter than 7 days, but on my first reading I got the
> opposite.
> >
> > Russ
> >
> >
> >> On Jan 24, 2021, at 6:03 PM, internet-dra...@ietf.org wrote:
> >>
> >>
> >> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >> This draft is a work item of the Transport Layer Security WG of the
> IETF.
> >>
> >>   Title   : Delegated Credentials for TLS
> >>   Authors : Richard Barnes
> >> Subodh Iyengar
> >> Nick Sullivan
> >> Eric Rescorla
> >>  Filename: draft-ietf-tls-subcerts-10.txt
> >>  Pages   : 19
> >>  Date: 2021-01-24
> >>
> >> Abstract:
> >>  The organizational separation between the operator of a TLS endpoint
> >>  and the certification authority can create limitations.  For example,
> >>  the lifetime of certificates, how they may be used, and the
> >>  algorithms they support are ultimately determined by the
> >>  certification authority.  This document describes a mechanism by
> >>  which operators may delegate their own credentials for use in TLS,
> >>  without breaking compatibility with peers that do not support this
> >>  specification.
> >>
> >>
> >> The IETF datatracker status page for this draft is:
> >> https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/
> >>
> >> There are also htmlized versions available at:
> >> https://tools.ietf.org/html/draft-ietf-tls-subcerts-10
> >> https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-10
> >>
> >> A diff from the previous version is available at:
> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-10
> >>
> >>
> >> Please note that it may take a couple of minutes from the time of
> submission
> >> until the htmlized version and diff are available at tools.ietf.org.
> >>
> >> Internet-Drafts are also available by anonymous FTP at:
> >> ftp://ftp.ietf.org/internet-drafts/
> >>
> >>
> >> ___
> >> 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 mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


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

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Alan DeKok]

On Jan 31, 2021, at 9:16 PM, Benjamin Kaduk  wrote:
> That's a scenario that I was starting to puzzle over this weekend as well
> -- with EAP-Success "completely unauthenticated", it would be fairly easy
> for an on-path attacker to send the EAP-Success the EAP peer was expecting
> and make the EAP peer think things succeeded even if the server had
> rejected the client cert.

  Yes.

>  Now, a server that has rejected the client cert
> is hopefully not going to be exporting the keys and continuing to run the
> next steps of protocol operation, but to some extent it seems that the
> security of the system as a whole relies on the server operating correctly
> in this regard.

  The TLS exporter keys are used for 802.1X / MacSec.  But they're not always 
used.

> ... it
> seems like a lot of what is being described as desired here ends up relying
> on ordering between application data and handshake messages.

  I think there's no implementation issue here.  The draft should be clearer 
that there's no guaranteed ordering.

> (A lot of my hedging in messages on this thread is because I also don't
> really understand why the message is there.)
> I believe I read somewhere that it stemmed from the change in who speaks
> last in the TLS handshake, but am a bit hazy on how that implies it is
> needed.

  I would like clarification on just what that message *means*.  If we want an 
explicit EAP layer signal that the server saw the client cert and authenticated 
it, then we MUST NOT send any such signal until after the server has seen the 
client cert.  And because the EAP-Success is sent all alone, we MUST then have 
another full round of TLS exchange, before the final EAP-Success.   i.e.


EAP-TLS Peer  EAP-TLS Server

 EAP-Request/
 <  Identity
EAP-Response/
Identity (Privacy-Friendly)  >
 EAP-Request/
EAP-Type=EAP-TLS
 <(TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
   (TLS ClientHello) >
 EAP-Request/
EAP-Type=EAP-TLS
(TLS ServerHello,
 TLS EncryptedExtensions,
  TLS CertificateRequest,
 TLS Certificate,
   TLS CertificateVerify,
 <---TLS Finished)
EAP-Response/
EAP-Type=EAP-TLS
   (TLS Certificate,
TLS CertificateVerify,
TLS Finished)>

 EAP-Request/
EAP-Type=EAP-TLS
 <(TLS Commitment Message)

EAP-Response/
EAP-Type=EAP-TLS
 (TLS Ack) >
 <   EAP-Success

  In that scenario, the commitment message *does* have a purpose:

*  It was not needed in TLS 1.2, because the "TLS Finished" message from the 
server came after the server saw the client cert. 
*  In TLS 1.3, that behaviour has changed
* so the *implicit* meaning of "server sends TLS finished" is no longer "server 
has seen client cert"
*  Since EAP-TLS wishes to authenticate the client cert, it MUST have an EAP 
state after the "TLS Finished" message
*  Since EAP-TLS does not provide for any data exchanged in the EAP layer, any 
data MUST be mangled into TLS
* and the only possibility is TLS application data.

  I'd like to know if any of these assumptions are false.

  If all this is true, then the 3.5 round EAP-TLS goal is impossible.

> I don't disagree with what you say, but I will note that if we are seeing a
> conflict between a desire to ship something ASAP and uncertainty that the
> current specification is fully correct, it's easy process-wise to allocate
> a new type code for people to ship "now" without locking in behavior for
> 0x0d.  Whether we call it an early allocation, an experimental usage, or a
> normal allocation via specification required doesn't seem terribly
> important (and given that Joe is the expert and he basically suggested it,
> I suspect that allocation would occur quite quickly after a request).
> How easy it would be to get things back onto 0x0d in the future is less
> clear, though.

  As an implementor, I fervently hope to *not* support an "ad hoc" EAP type for 
the next 10 years.

  My preference is to get this right, even it means more delays.

  Alan DeKok.

___

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Alan DeKok]

On Feb 1, 2021, at 1:00 AM, Joseph Salowey  wrote:
[ re: commitment message ]

> [Joe]  I'm not sure why it's needed. It's not clear to me why the peer can't 
> hold the TLS session open until it receives more TLS messages (handshake or 
> alert) or an EAP failure or EAP Success.  

  I suspect that it can.

  The larger issue for me is that in EAP + TLS 1.2, the "TLS Finished" message 
comes after the client certificate has been validated.  See Page 6 of 
https://tools.ietf.org/html/rfc5216

  In EAP + TLS 1.3, the proposal is that the "TLS Finished" message comes 
before the client certificate has been validated.

  To me, this means that the client has absolutely no idea whether or not it's 
certificate has been verified.  Any malicious actor could forge an EAP-Success 
(as it is entirely unauthenticated).  This seems to be a major difference from 
TLS 1.2, and potentially a major problem.

  There is a goal to get EAP-TLS working in 3.5 rounds.  That's a good goal, 
but I'd like to be sure that it doesn't come at the expense of security.

  Alan DeKok.

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