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

[John Mattsson]

Hi,

I can live with any version, the important thing is that interoperable 
implementations get shipped ASAP. This is important also for 3GPP as EAP-TLS 
1.3 is mandatory to support in 3GPP Rel-16 if EAP-TLS is supported.

We (the authors) have addressed all the comments from IESG/TLS WG in GitHub.

https://github.com/emu-wg/draft-ietf-emu-eap-tls13/tree/master

Text format:

https://emu-wg.github.io/draft-ietf-emu-eap-tls13/draft-ietf-emu-eap-tls13.txt

The diff can be found here:

https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-emu-eap-tls13.txt&url2=https://emu-wg.github.io/draft-ietf-emu-eap-tls13/draft-ietf-emu-eap-tls13.txt

This would be ready for submission but I think the Implementors, WGs, Chairs, 
Shepard, ADs need to agree on the direction before we do that. The two 
important technical changes from -13 are

(1) Changing key derivation
(2) Changing Commitment message to close_notify

The key derivation changes are good and more modern. I personally like the 
change but the change but I don't think it is essential and was not done for 
security reasons.

The close_notity changes are not only positive as it sometimes introduce an 
additional roundtrip. The Commitment message can according to specification be 
sent with the server Finish even if some/most/all implementation does not seem 
to allow this. If the commitment message cannot be send with Finished in 
practice there is no difference in latency. Still a bit sad how poorly TLS 1.3 
and EAP interacts. I am not sure I fully agree with the layer violation 
argument, my interpretation was that this was information for the EAP state 
machine which is the application using TLS. Maybe the text regarding the 
commitment message was badly written and should have talked about the EAP state 
machine more instead of TLS

We need to get agreement on how to proceed here asap. I would like implementors 
and security AD to agree on the way forward before submitting -14. Four ways 
forward:

A. Add (1) and (2)
B. Only add (1)
C. Only add (2)
D. Do not add (1) or (2)

I assume implementors (Alan, Jorge) are fine with all other changes since -13.

Do we need to have a telephone meeting to discuss these things? We cannot have 
a formal interim meeting as that formally takes weeks to setup. This can also 
not wait until the next IETF. As soon as we agree on a way forward we can 
update and submit a new version within 24 h.

Cheers,
John

-Original Message-
From: TLS  on behalf of Jorge Vergara 

Date: Friday, 29 January 2021 at 00:57
To: Alan DeKok , Martin Thomson 
Cc: "TLS@ietf.org" , EMU WG 
Subject: Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on 
draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

I am in favor of sticking to draft-13. There was some discussion about whether 
draft-13 contained a TLS layering violation, but I believe that discussion 
concluded that it does not. As noted, discussion has mostly stalled since then 
with a few additional ideas surfacing that have added round trips. Other 
threads are now popping up expressing dissatisfaction with the extra round trip.

Alan mentions that betas may be months out for his product line - for Microsoft 
and Windows, the situation is much tighter. If we cannot reach consensus 
quickly we will need to push this out of our 2021 release cycle. Seeing as 
we're sitting on draft-13 with multiple implementations available, I would 
really prefer to reach consensus to finalize draft-13 and get this into the 
hands of customers this calendar year.

Jorge Vergara

-Original Message-
From: Emu  On Behalf Of Alan DeKok
Sent: Saturday, January 23, 2021 2:28 PM
To: Martin Thomson 
Cc:  ; EMU WG 
Subject: Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on 
draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

  We're approaching 2 weeks since the last discussion of this topic.  This 
document has been in development for 3 years.  We desperately need to finish 
it.  IMHO waiting another 6 months is not an option.  Even 3 would be worrying.

  We have multiple inter-operable implementations which have implemented 
draft-13.  That work over the last few months have resulted in implementors 
making plans to do beta testing in the next few weeks.  Those plans have been 
put on indefinite hold, due to the recent request for changes.

  I understand getting feedback from the TLS WG is useful.  But I would prefer 
to have consensus on a *solution*. Right now, we just have a series of proposed 
changes, with little to no discussion.

  We're getting to the point where we have to ship code as promised to 
customers soon (weeks, not months).  We therefore need consensus, as soon as 
possible.

  My preference is to implement draft-13.  We know the code works.  People are 
ready to ship it.  Any changes will add not just more months of standard 
discussion, but more months of interoperability testing.

  If there is no progress in EMU, we're looking at September for firs

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

[Alan DeKok]

On Jan 29, 2021, at 5:31 AM, John Mattsson  wrote:
> 
> I can live with any version, the important thing is that interoperable 
> implementations get shipped ASAP. This is important also for 3GPP as EAP-TLS 
> 1.3 is mandatory to support in 3GPP Rel-16 if EAP-TLS is supported.

  Then our choices are:

a) draft-13 in February.  There are multiple interoperable implementations, 
including Microsoft, FreeRADIUS, and hostap / wpa_supplicant.

b) ??? in 2021.

> The close_notity changes are not only positive as it sometimes introduce an 
> additional roundtrip. The Commitment message can according to specification 
> be sent with the server Finish even if some/most/all implementation does not 
> seem to allow this. If the commitment message cannot be send with Finished in 
> practice there is no difference in latency. Still a bit sad how poorly TLS 
> 1.3 and EAP interacts.

  The TLS implementations largely assume that TLS is being used (a) over TCP, 
and (b) to exchange application data.  These assumptions *severely* limit the 
choices available for implementors of EAP-TLS.

  We can verify these assumptions by simply noting that many TLS 
implementations include native support for TLS over TCP.  While there have been 
assertions that TLS libraries also implement EAP, those assertions seem to be 
firmly outside of the bounds of reality.

> We need to get agreement on how to proceed here asap. I would like 
> implementors and security AD to agree on the way forward before submitting 
> -14. Four ways forward:
> 
> A. Add (1) and (2)
> B. Only add (1)
> C. Only add (2)
> D. Do not add (1) or (2)

  My strong preference is (D).

> I assume implementors (Alan, Jorge) are fine with all other changes since -13.

  Yes,

> Do we need to have a telephone meeting to discuss these things? We cannot 
> have a formal interim meeting as that formally takes weeks to setup. This can 
> also not wait until the next IETF. As soon as we agree on a way forward we 
> can update and submit a new version within 24 h.

  TBH, implementors have already had multiple informal discussions and calls.  
One more wouldn't make much difference.

  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 Jan 29, 2021, at 8:10 AM, Alan DeKok  wrote:
>  Then our choices are:
> 
> a) draft-13 in February.  There are multiple interoperable implementations, 
> including Microsoft, FreeRADIUS, and hostap / wpa_supplicant.
> 
> b) ??? in 2021.

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

[TLS] Comment on Section 6.1 Closure Alerts in draft-ietf-tls-rfc8446bis-00

[John Mattsson]

Hi,

I think Section 6.1 Closure Alerts is a bit unclear:

First it is stated the user_canceled SHOULD be followed by close_notify

   "This alert SHOULD be followed by a "close_notify"." 

Then it is stated that it MUST be followed by close_notify

   "Each party MUST send a "close_notify" alert before closing its write side 
of the connection,
   unless it has already sent some error alert."

And in the same section is is stated that any data folloing user_canceled MUST 
be ignored.

   "Any data received after a closure alert has been received MUST be ignored."

This seems quite contradicting to me. I don't know what the correct behavior 
would be,
but unless I misunderstood something, it looks like it should be addressed in 
rfc8446bis.

Cheers,
John

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

Re: [TLS] Comment on Section 6.1 Closure Alerts in draft-ietf-tls-rfc8446bis-00

[Eric Rescorla]

Good catch. I have filed https://github.com/tlswg/tls13-spec/issues/1208 to
address it.

-Ekr


On Fri, Jan 29, 2021 at 6:29 AM John Mattsson  wrote:

> Hi,
>
> I think Section 6.1 Closure Alerts is a bit unclear:
>
> First it is stated the user_canceled SHOULD be followed by close_notify
>
>"This alert SHOULD be followed by a "close_notify"."
>
> Then it is stated that it MUST be followed by close_notify
>
>"Each party MUST send a "close_notify" alert before closing its write
> side of the connection,
>unless it has already sent some error alert."
>
> And in the same section is is stated that any data folloing user_canceled
> MUST be ignored.
>
>"Any data received after a closure alert has been received MUST be
> ignored."
>
> This seems quite contradicting to me. I don't know what the correct
> behavior would be,
> but unless I misunderstood something, it looks like it should be addressed
> in rfc8446bis.
>
> Cheers,
> John
>
> ___
> 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] Barry Leiba's No Objection on draft-ietf-tls-ticketrequests-07: (with COMMENT)

[Sean Turner]

> On Dec 16, 2020, at 00:18, Barry Leiba via Datatracker  
> wrote:
> 
> Barry Leiba has entered the following ballot position for
> draft-ietf-tls-ticketrequests-07: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Thanks for a very clear, well-written document.  Just one very tiny comment:
> 
> — Section 1.1 —
> Please use the exact BCP 14 boilerplate from RFC 8174 (this one is missing 
> “BCP 14”).

Eagle eye! I would like to propose that we leave this one to the RFC editor.

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

[TLS] Frequent ephemeral Diffie-Hellman in long-term (D)TLS 1.3 connections replacing IPsec

[John Mattsson]

Hi,

3GPP has historically to a large degree used IPsec to protect interfaces in the 
core and radio access networks. Recently, 3GPP has more and more been 
specifying use of (D)TLS to replace or complement IPsec. Most 3GPP usage of 
(D)TLS are long-term connections. 

Current best practice for long-term connections is to rerun Ephemeral 
Diffie-Hellman frequently to limit the impact of a key compromise. For IPsec, 
ANSSI (France) recommends to rerun Ephemeral Diffie-Hellman every hour and 
every 100 GB, BSI (Germany) recommend at least every 4 h, and NIST (USA) 
recommends at least every 8 h. These recommendations are formally for IPsec but 
makes equal sense for any long-term connection such as (D)TLS.

If I understand correctly, the KeyUpdate handshake message only provides 
Forward Secrecy (compromise of the current key does not compromise old keys). 
To ensure that compromise of the current key does not compromise future keys 
(post-compromise security, backward secrecy, future secrecy) my understanding 
is that one would have to frequently terminate the connection and do resumption 
with psk_dh_ke. Seems like this would cause a noticeable interruption in the 
connection, or? Are there any best practice for how to do frequent ephemeral 
Diffie-Hellman for long-term (D)TLS connections? Seems to me that frequent 
ephemeral Diffie-Hellman should be the recommendation for any long-term (D)TLS 
connection as it is for IPsec.

Cheers,
John

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

Re: [TLS] Éric Vyncke's No Objection on draft-ietf-tls-ticketrequests-07: (with COMMENT)

[Sean Turner]

> On Dec 14, 2020, at 02:52, Éric Vyncke via Datatracker  
> wrote:
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-tls-ticketrequests-07: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Thank you for the work put into this document. It is short and easy to
> understand.
> 
> I find that the contents of section 1 and of section 2 are quite duplicate.

While true, I do sometimes find we end up here because there have been requests 
to move information forward to the introduction in the draft. Unfortunately, 
that results in some duplication. I would like to propose that if the draft 
does not contradict itself that we leave it as is.

> In section 2, the use of capitalized word after a ":" looks weird to me but I
> am not a native English speaker.

I suspect that his might be a style thing so I would like to leave this one for 
the RFC editor.

> I hope that this helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> 
> 

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

Re: [TLS] Murray Kucherawy's No Objection on draft-ietf-tls-ticketrequests-07: (with COMMENT)

[Sean Turner]

> On Dec 14, 2020, at 01:50, Murray S. Kucherawy  wrote:
> 
> On Sun, Dec 13, 2020 at 10:41 PM Benjamin Kaduk  wrote:
> > Some places in this document use "reuse", others "re-use".  I'm not sure 
> > which
> > one is right, but it should be consistent throughout.
> 
> Both are (or, rather, can be) correct, if you treat "reuse" is a noun and
> "re-use" is a verb.
> 
> (It's hardly a major point, but since you said that...)
> 
> I thought that might have been the case so I checked before balloting.  In 
> all cases the word is preceded by "ticket", making it a noun.
> 
> -MSK

The other nice thing here is that the RFC editor will do its thing during 
AUTH48 to make sure we have these right.

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

Re: [TLS] Barry Leiba's No Objection on draft-ietf-tls-ticketrequests-07: (with COMMENT)

[Barry Leiba]

> > — Section 1.1 —
> > Please use the exact BCP 14 boilerplate from RFC 8174 (this one is missing 
> > “BCP 14”).
>
> Eagle eye! I would like to propose that we leave this one to the RFC editor.

Sure; maybe Ben can stick in an RFC Editor note to make sure they notice it.

Thanks,
Barry

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

Re: [TLS] Éric Vyncke's No Objection on draft-ietf-tls-ticketrequests-07: (with COMMENT)

[Eric Vyncke (evyncke)]

Sean,

Thank you for your reply. I am of course happy with them ;-)

Regards

-éric

-Original Message-
From: Sean Turner 
Date: Friday, 29 January 2021 at 16:54
To: Eric Vyncke 
Cc: The IESG , "draft-ietf-tls-ticketreque...@ietf.org" 
, TLS Chairs , TLS 
List 
Subject: Re: Éric Vyncke's No Objection on draft-ietf-tls-ticketrequests-07: 
(with COMMENT)



> On Dec 14, 2020, at 02:52, Éric Vyncke via Datatracker  
wrote:
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-tls-ticketrequests-07: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Thank you for the work put into this document. It is short and easy to
> understand.
> 
> I find that the contents of section 1 and of section 2 are quite 
duplicate.

While true, I do sometimes find we end up here because there have been 
requests to move information forward to the introduction in the draft. 
Unfortunately, that results in some duplication. I would like to propose that 
if the draft does not contradict itself that we leave it as is.

> In section 2, the use of capitalized word after a ":" looks weird to me 
but I
> am not a native English speaker.

I suspect that his might be a style thing so I would like to leave this one 
for the RFC editor.

> I hope that this helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> 
> 


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

[Jorge Vergara]

> We need to get agreement on how to proceed here asap. I would like 
> implementors and security AD to agree on the way forward before submitting 
> -14. Four ways forward:
> 
> A. Add (1) and (2)
> B. Only add (1)
> C. Only add (2)
> D. Do not add (1) or (2)

My preference is D.

> Do we need to have a telephone meeting to discuss these things? We cannot 
> have a formal interim meeting as that formally takes weeks to setup. This can 
> also not wait until the next IETF. As soon as we agree on a way forward we 
> can update and submit a new version within 24 h.

Totally open to this.

Jorge Vergara

-Original Message-
From: Alan DeKok  
Sent: Friday, January 29, 2021 5:10 AM
To: John Mattsson 
Cc: Jorge Vergara ; Martin Thomson 
; Benjamin Kaduk ; Roman Danyliw 
;  ; EMU WG 
Subject: Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on 
draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

On Jan 29, 2021, at 5:31 AM, John Mattsson  wrote:
> 
> I can live with any version, the important thing is that interoperable 
> implementations get shipped ASAP. This is important also for 3GPP as EAP-TLS 
> 1.3 is mandatory to support in 3GPP Rel-16 if EAP-TLS is supported.

  Then our choices are:

a) draft-13 in February.  There are multiple interoperable implementations, 
including Microsoft, FreeRADIUS, and hostap / wpa_supplicant.

b) ??? in 2021.

> The close_notity changes are not only positive as it sometimes introduce an 
> additional roundtrip. The Commitment message can according to specification 
> be sent with the server Finish even if some/most/all implementation does not 
> seem to allow this. If the commitment message cannot be send with Finished in 
> practice there is no difference in latency. Still a bit sad how poorly TLS 
> 1.3 and EAP interacts.

  The TLS implementations largely assume that TLS is being used (a) over TCP, 
and (b) to exchange application data.  These assumptions *severely* limit the 
choices available for implementors of EAP-TLS.

  We can verify these assumptions by simply noting that many TLS 
implementations include native support for TLS over TCP.  While there have been 
assertions that TLS libraries also implement EAP, those assertions seem to be 
firmly outside of the bounds of reality.

> We need to get agreement on how to proceed here asap. I would like 
> implementors and security AD to agree on the way forward before submitting 
> -14. Four ways forward:
> 
> A. Add (1) and (2)
> B. Only add (1)
> C. Only add (2)
> D. Do not add (1) or (2)

  My strong preference is (D).

> I assume implementors (Alan, Jorge) are fine with all other changes since -13.

  Yes,

> Do we need to have a telephone meeting to discuss these things? We cannot 
> have a formal interim meeting as that formally takes weeks to setup. This can 
> also not wait until the next IETF. As soon as we agree on a way forward we 
> can update and submit a new version within 24 h.

  TBH, implementors have already had multiple informal discussions and calls.  
One more wouldn't make much difference.

  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)

[Benjamin Kaduk]

Hi Alan,

I see that the thread is continuing and that perhaps my reply will even
become stale as I write it, but I'm replying to your note instead of the
tip of the thread because it has good context for making some broader
points that I would like to make.

On Sat, Jan 23, 2021 at 05:28:10PM -0500, Alan DeKok wrote:
>   We're approaching 2 weeks since the last discussion of this topic.  This 
> document has been in development for 3 years.  We desperately need to finish 
> it.  IMHO waiting another 6 months is not an option.  Even 3 would be 
> worrying.

My understanding of the discussions involving the TLS WG are that we forked
off into two sub-threads: one about the use of TLS Exporters for key
derivation (the one this is a reply to), that largely concluded with
agreement on a simple change to make, and the other sub-thread about the
protocol element known in -13 as the "commitment message".

With respect to the exporter usage, I do see you had asked about using the
type-code as the exporter context value that Martin didn't see much value
in, but I am willing to accept that as a boon for safety of portability to
other TLS-using EAP mechanisms.  (I do note that the current editor's copy
shows calls to TLS-Exporter() with only two arguments, but three are
required; the construction there also seems to include a propspect for
violation of the requirement that "one label is not a prefix of any other
label" when both regular one-byte and extended type codes are used, but if
the type code is meant to be the context argument I believe that risk goes
away.)

With respect to the "commitment message", I thought we had a discussion
that revealed that the mechanism in the -13 could not fulfil its stated
purpose, and that also called into question whether that stated purpose was
actually the right thing that the protocol needed.  My understanding,
therefore, was that the TLS WG could not contribute further insight until
there was a revised proposal from people who understand the needs of the
EAP-TLS protocol from TLS that would both satisfy the needs of EAP and
actually be achievable.

>   We have multiple inter-operable implementations which have implemented 
> draft-13.  That work over the last few months have resulted in implementors 
> making plans to do beta testing in the next few weeks.  Those plans have been 
> put on indefinite hold, due to the recent request for changes.
> 
>   I understand getting feedback from the TLS WG is useful.  But I would 
> prefer to have consensus on a *solution*. Right now, we just have a series of 
> proposed changes, with little to no discussion.

I think this is becaues the TLS WG members (in aggregate) do not have a
clear picture of what property or properties EAP-TLS will require from TLS
that led to the need for an additional message when using TLS 1.3 as
opposed to the RFC 5216 case with TLS 1.2.  The prospect of an
"authenticated signal from TLS to EAP-TLS that the authentication completed
successfully" was mentioned, but I did not have the sense that there was
universal agreement of that as the sole relevant property.

>   We're getting to the point where we have to ship code as promised to 
> customers soon (weeks, not months).  We therefore need consensus, as soon as 
> possible.
> 
>   My preference is to implement draft-13.  We know the code works.  People 
> are ready to ship it.  Any changes will add not just more months of standard 
> discussion, but more months of interoperability testing.
> 
>   If there is no progress in EMU, we're looking at September for first betas. 
>  With no guarantee that there won't be further changes made after that.
> 
>   So the question is:
> 
> * are the draft-13 0x00 byte and exporter *terrible* enough to delay the 
> standard another 6 months?

Well, the text of the -13 contains a protocol mechanism that cannot deliver
its stated purpose, so I will continue to hold a Discuss position if that
remains.  One Discuss ballot does not have to block the work indefinitely
(the shepherding AD can request a different IESG balloting procedure be
used), and I leave it between the WG and Roman whether to attempt that
route.  It is perhaps possible that (as John noted downthread) the text
about the commitment message was badly written, and that just changing the
surrounding description could work, but that gets back to the question I
mentioned above of what properties EAP-TLS actually requires from TLS.

-Ben

> * if the answer is "no", then we can ship now.
> 
> * if the answer is 'yes", then the next question is "when can we get this 
> finalized?"  "March" would be late.  "July" is a major problem.
> 
> > On Jan 12, 2021, at 10:22 AM, Alan DeKok  wrote:
> > 
> > On Jan 11, 2021, at 7:08 PM, Martin Thomson  wrote:
> >> I was not exactly.  I was thinking that EAP-TLS uses the unadorned string 
> >> and other usages (that need a different MSK) define their own string as 
> >> needed.
> > 
> >  Which is largely what was done for <= TLS 1.2.

Re: [TLS] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

[Sean Turner]

> On Jan 21, 2021, at 16:50, Daniel Migault  wrote:
> 
> Hi, 
> 
> First I deeply apologize for taking so long to respond, I just realized now 
> these responses. 

No worries it does happen that I miss email from time to time too ;)

> I do not believe a review of IoT protocol is needed, I am more thinking that 
> TLS document should serve as a base guidance for TLS. Specific needs for IoT 
> are addressed based on the generic guidances. In some cases specific 
> extensions, cipher suites - not referenced by IANA as recommended - will be 
> needed to address specific corner cases. 

I agree with you since the TLS RFC provides the general use case. Other RFCs 
can specify other use cases. The way we handled this for CCM_8 suites was to 
include the following note:

Note
CCM_8 cipher suites are not marked as "Recommended".  These
cipher suites have a significantly truncated authentication tag
that represents a security trade-off that may not be appropriate
for general environments.

spt

> Yours, 
> Daniel  
> 
> On Tue, Oct 27, 2020 at 11:32 PM Sean Turner  wrote:
> 
> 
> > On Oct 27, 2020, at 10:32, Daniel Migault  wrote:
> > 
> > To address the comment below, keeping weak security is likely to weaken 
> > current and future IoT communications, so I do not think there is room for 
> > compromise with performance. Of course this is in a context of TLS.  I 
> > expect protocol to leverage from TLS security, so the impact should be 
> > rather negligible. 
> > 
> > """
> > As those hash algorithms were 'cheap' for TLS 1.2, I would appreciate a 
> > review of impacted IoT protocols if those algorithms are deprecated.
> > """
> 
> In terms of process, are you suggesting "a review of impacted IoT protocols 
> if those algorithms are deprecated” MUST be completed prior to advancing this 
> document to the IESG?
> 
> spt
> 
> > Yours, 
> > Daniel
> > 
> > 
> > On Tue, Oct 27, 2020 at 10:21 AM Daniel Migault via Datatracker 
> >  wrote:
> > Reviewer: Daniel Migault
> > Review result: Ready with Nits
> > 
> > Hi,
> > 
> > 
> > I reviewed this document as part of the IoT Directorate's ongoing effort to
> > review all IETF documents being processed by the IESG.  These comments were
> > written primarily for the benefit of the Security Area Directors.  Document
> > authors, document editors, and WG chairs should treat these comments just 
> > like
> > any other IETF Last Call comments.  
> > 
> > Review Results: Ready with Nits
> > 
> > Please find my comments below.
> > 
> > Yours,
> > Daniel
> > 
> > 
> >  Deprecating MD5 and SHA-1 signature hashes in TLS 1.2
> >   draft-ietf-tls-md5-sha1-deprecate-04
> > [...]
> > 
> > 1.  Introduction
> > 
> >The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is
> >specified in [RFC5246].  MD5 and SHA-1 have been proven to be
> >insecure, subject to collision attacks [Wang].  In 2011, [RFC6151]
> >detailed the security considerations, including collision attacks for
> >MD5.  NIST formally deprecated use of SHA-1 in 2011
> >[NISTSP800-131A-R2] and disallowed its use for digital signatures at
> >the end of 2013, based on both the Wang, et. al, attack and the
> >potential for brute-force attack.  In 2016, researchers from INRIA
> >identified a new class of transcript collision attacks on TLS (and
> >other protocols) that rely on efficient collision-finding algorithms
> >on the underlying hash constructions [Transcript-Collision].
> >Further, in 2017, researchers from Google and CWI Amsterdam
> >[SHA-1-Collision] proved SHA-1 collision attacks were practical.
> >This document updates [RFC5246] and [RFC7525] in such a way that MD5
> >and SHA-1 MUST NOT be used for digital signatures.  However, this
> >document does not deprecate SHA-1 in HMAC for record protection.
> > 
> > 
> > RFC6194 may be mentioned as a reference for
> > not deprecating HMAC-SHA-1 as well as an
> > additional reference to [NISTSP800-131A-R2]. 
> > 
> > Reading the text the situation of HMAC with
> > MD5 is unclear. Since we specify that SHA-1
> > is not deprecated for HMAC we may specify
> > the status for HMAC with MD5. Given RFC6151 I
> > hope the reason is that MD5 and HMAC-MD5 has
> > already been deprecated but I have not found
> > this. Maybe that would worth mentioning it
> > is deprecated already.
> > 
> > 
> > 
> > [...]
> > 
> > 2.  Signature Algorithms
> > 
> >Clients MUST NOT include MD5 and SHA-1 in the signature_algorithms
> >extension.  If a client does not send a signature_algorithms
> >extension, then the server MUST abort the handshake and send a
> >handshake_failure alert, except when digital signatures are not used
> >(for example, when using PSK ciphers).
> > 
> > 
> > It seems to me that the server behavior might
> > be defined as well. In our case this could be
> > something around the lines the server MUST
> > ignore MD5 and SHA1 values in the signature
> > algorithm extens

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

[Alan DeKok]

On Jan 29, 2021, at 1:32 PM, Benjamin Kaduk  wrote:
> With respect to the exporter usage, I do see you had asked about using the
> type-code as the exporter context value that Martin didn't see much value
> in, but I am willing to accept that as a boon for safety of portability to
> other TLS-using EAP mechanisms.

  OK. 

>  (I do note that the current editor's copy
> shows calls to TLS-Exporter() with only two arguments, but three are
> required; the construction there also seems to include a propspect for
> violation of the requirement that "one label is not a prefix of any other
> label" when both regular one-byte and extended type codes are used, but if
> the type code is meant to be the context argument I believe that risk goes
> away.)

  The EAP type codes are one octet: 0x00 through 0xfd.  The "expanded" type 
codes begin with 0xfe.  So there is no prefix issue, even if the type codes 
form part of the label.

  That being said, using them as the context is preferred, I think.

> With respect to the "commitment message", I thought we had a discussion
> that revealed that the mechanism in the -13 could not fulfil its stated
> purpose, and that also called into question whether that stated purpose was
> actually the right thing that the protocol needed.

  I'm less sure.  There was a lot of discussion around a lot of things.  Part 
of the issue seems to be that bits of the TLS state machine are underspecified 
so far as the EAP needs go.

  i.e. when Z happens, is A guaranteed to have happened before that?  RFC 8446 
is not clear.

> I think this is becaues the TLS WG members (in aggregate) do not have a
> clear picture of what property or properties EAP-TLS will require from TLS
> that led to the need for an additional message when using TLS 1.3 as
> opposed to the RFC 5216 case with TLS 1.2.  The prospect of an
> "authenticated signal from TLS to EAP-TLS that the authentication completed
> successfully" was mentioned, but I did not have the sense that there was
> universal agreement of that as the sole relevant property.

  The issue is in part due to API limitations in OpenSSL.  I will send a 
separate message summarizing the issues.

> Well, the text of the -13 contains a protocol mechanism that cannot deliver
> its stated purpose, so I will continue to hold a Discuss position if that
> remains.  One Discuss ballot does not have to block the work indefinitely
> (the shepherding AD can request a different IESG balloting procedure be
> used), and I leave it between the WG and Roman whether to attempt that
> route.  It is perhaps possible that (as John noted downthread) the text
> about the commitment message was badly written, and that just changing the
> surrounding description could work, but that gets back to the question I
> mentioned above of what properties EAP-TLS actually requires from TLS.

  I've had some further discussions and will send a separate message 
summarizing the issues.

  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)

[Mohit Sethi M]

Hi Ben,

On 1/29/21 8:32 PM, Benjamin Kaduk wrote:

Hi Alan,

I see that the thread is continuing and that perhaps my reply will even
become stale as I write it, but I'm replying to your note instead of the
tip of the thread because it has good context for making some broader
points that I would like to make.

On Sat, Jan 23, 2021 at 05:28:10PM -0500, Alan DeKok wrote:


  We're approaching 2 weeks since the last discussion of this topic.  This 
document has been in development for 3 years.  We desperately need to finish 
it.  IMHO waiting another 6 months is not an option.  Even 3 would be worrying.



My understanding of the discussions involving the TLS WG are that we forked
off into two sub-threads: one about the use of TLS Exporters for key
derivation (the one this is a reply to), that largely concluded with
agreement on a simple change to make, and the other sub-thread about the
protocol element known in -13 as the "commitment message".

With respect to the exporter usage, I do see you had asked about using the
type-code as the exporter context value that Martin didn't see much value
in, but I am willing to accept that as a boon for safety of portability to
other TLS-using EAP mechanisms.  (I do note that the current editor's copy
shows calls to TLS-Exporter() with only two arguments, but three are
required; the construction there also seems to include a propspect for
violation of the requirement that "one label is not a prefix of any other
label" when both regular one-byte and extended type codes are used, but if
the type code is meant to be the context argument I believe that risk goes
away.)

RFC 5705 says:

   If no context is provided, it then computes:

   PRF(SecurityParameters.master_secret, label,
   SecurityParameters.client_random +
   SecurityParameters.server_random
   )[length]

   If context is provided, it computes:

   PRF(SecurityParameters.master_secret, label,
   SecurityParameters.client_random +
   SecurityParameters.server_random +
   context_value_length + context_value
   )[length]


We use only two arguments and say "No context data is used in the TLS exporter 
interface.". We could show the context argument as empty in the calls to make 
things clearer. By the way, this is what is done by TEAP also. RFC 7170 says 
"TEAPv1 makes use of the TLS Keying Material Exporters defined in [RFC5705] to 
derive the session_key_seed.  The label used in the derivation is "EXPORTER: 
teap session key seed".  The length of the session key seed material is 40 
octets.  No context data is used in the export process."

The change of moving the type-code from the context to the label was made based 
on your review (comments from Martin) and the fact that some libraries such as 
wolfssl don't support passing a context (so far). See: 
https://w1.fi/cgit/hostap/tree/src/crypto/tls_wolfssl.c#n1996



With respect to the "commitment message", I thought we had a discussion
that revealed that the mechanism in the -13 could not fulfil its stated
purpose, and that also called into question whether that stated purpose was
actually the right thing that the protocol needed.  My understanding,
therefore, was that the TLS WG could not contribute further insight until
there was a revised proposal from people who understand the needs of the
EAP-TLS protocol from TLS that would both satisfy the needs of EAP and
actually be achievable.



  We have multiple inter-operable implementations which have implemented 
draft-13.  That work over the last few months have resulted in implementors 
making plans to do beta testing in the next few weeks.  Those plans have been 
put on indefinite hold, due to the recent request for changes.

  I understand getting feedback from the TLS WG is useful.  But I would prefer 
to have consensus on a *solution*. Right now, we just have a series of proposed 
changes, with little to no discussion.



I think this is becaues the TLS WG members (in aggregate) do not have a
clear picture of what property or properties EAP-TLS will require from TLS
that led to the need for an additional message when using TLS 1.3 as
opposed to the RFC 5216 case with TLS 1.2.  The prospect of an
"authenticated signal from TLS to EAP-TLS that the authentication completed
successfully" was mentioned, but I did not have the sense that there was
universal agreement of that as the sole relevant property.

I think there was a misunderstanding that an authenticated signal of 
authentication completed was needed. Only a signal of no more post handshake 
messages was needed. I think Alan's summary might also explain the situation 
better.

--Mohit





  We're getting to the point where we have to ship code as promised to 
customers soon (weeks, not months).  We therefore need consensus, as soon as 
possible.

  My preference is to implement draft-13.  We know the code works.  People are 
ready to ship it.  Any change

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

[Alan DeKok]

  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.e. there would be no TLS layer signalling for the following situations:

   bad_certificate,  unsupported_certificate,  certificate_revoked,  
certificate_expired, certificate_unknown,  illegal_parameter, unknown_ca, 
access_denied, etc

  This limitation would be an unmitigated disaster for EAP-TLS.  Those messages 
are required by people deploying EAP-TLS.  Without those messages, it will be 
near impossible to debug configuration issues.

  As a result, we cannot use CloseNotify to signal "no more handshake messages" 
from the server.

  There is a related issue, in that TLS 1.3 separates Session Tickets from TLS 
handshakes.  So it's still possible for the EAP state machine to send a 0x00 
octet, and then the TLS state machines sends that *before* a Session Ticket.

  In addition, RFC 8446 Figure 1 shows that application data can be sent by the 
server to the client, *before* the client certificate is sent to the server.  
So sending this octet in EAP-TLS does not prove that the client certificate has 
been validated.

DISCUSS: the EAP-TLS draft should explain that the 0x00 byte is NOT a positive 
signal of either "finished TLS", or "successful authentication".

DISCUSS: the EAP-TLS draft should also explain that session tickets may be sent 
either before or after the 0x00 octet.  Does the packet flow look any different 
for the two cases?  If so, what does that mean?

DISCUSS: We have interoperable implementations of -13.  Does this mean that the 
EAP state machines *implicitly* work with the TLS state machines?  There is no 
*explicit* requirement in the draft about ordering, and no discussion thereof.  
I suspect that this means the implementations work in part by accident, instead 
of by design.  So updates to TLS libraries *may* break EAP-TLS.  It would be 
best to make any assumptions explicit.  And / or to recommend to implementors 
that they be flexible with respect to changing order of the 0x00 octet vs 
session tickets.


  In situations where resumption is not needed, figure 1 of 
https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-13 is correct.  There are 
3.5 rounds, which is about as low as possible.  Adding resumption here would 
*increase* there number of rounds to 4.5, which is worse!

DISCUSS: the EAP-TLS draft Section 2.1.1 should be updated to note that this 
examples does not include Session Tickets.  Section 2.1.2 should be updated to 
note that there are more rounds than for the previous section.


  In situations where the certificate chain is longer, the initial 
authentication will be >=4.5 round trips, and session tickets are perhaps more 
useful.

DISCUSS: the EAP-TLS draft should be updated to better explain the costs / 
benefits of using resumption


  I hope that this summary clarifies the issues and requirements.  The 0x00 
octet is intended as a promise that no more handshake messages are sent.  I 
leave it to others to discuss whether or not that promise is useful.

  As for what to do, my $0.02 is that the behaviour described in -13 is fine.  
The 0x00 octet is useful.  The key exporters are perhaps odd, but not 
problematic.  We have multiple inter-operable implementations.

  The remaining question is this:

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?

  The only advice I offer here is that we *cannot* rev EAP-TLS, as there is no 
"version" flag in the EAP-TLS h

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

[Joseph Salowey]

On Fri, Jan 29, 2021 at 11:34 AM Mohit Sethi M  wrote:

> Hi Ben,
> On 1/29/21 8:32 PM, Benjamin Kaduk wrote:
>
> Hi Alan,
>
> I see that the thread is continuing and that perhaps my reply will even
> become stale as I write it, but I'm replying to your note instead of the
> tip of the thread because it has good context for making some broader
> points that I would like to make.
>
> On Sat, Jan 23, 2021 at 05:28:10PM -0500, Alan DeKok wrote:
>
>   We're approaching 2 weeks since the last discussion of this topic.  This 
> document has been in development for 3 years.  We desperately need to finish 
> it.  IMHO waiting another 6 months is not an option.  Even 3 would be 
> worrying.
>
> My understanding of the discussions involving the TLS WG are that we forked
> off into two sub-threads: one about the use of TLS Exporters for key
> derivation (the one this is a reply to), that largely concluded with
> agreement on a simple change to make, and the other sub-thread about the
> protocol element known in -13 as the "commitment message".
>
> With respect to the exporter usage, I do see you had asked about using the
> type-code as the exporter context value that Martin didn't see much value
> in, but I am willing to accept that as a boon for safety of portability to
> other TLS-using EAP mechanisms.  (I do note that the current editor's copy
> shows calls to TLS-Exporter() with only two arguments, but three are
> required; the construction there also seems to include a propspect for
> violation of the requirement that "one label is not a prefix of any other
> label" when both regular one-byte and extended type codes are used, but if
> the type code is meant to be the context argument I believe that risk goes
> away.)
>
> RFC 5705 says:
>
>If no context is provided, it then computes:
>
>PRF(SecurityParameters.master_secret, label,
>SecurityParameters.client_random +
>SecurityParameters.server_random
>)[length]
>
>If context is provided, it computes:
>
>PRF(SecurityParameters.master_secret, label,
>SecurityParameters.client_random +
>SecurityParameters.server_random +
>context_value_length + context_value
>)[length]
>
> We use only two arguments and say "No context data is used in the TLS
> exporter interface.". We could show the context argument as empty in the
> calls to make things clearer. By the way, this is what is done by TEAP
> also. RFC 7170 says "TEAPv1 makes use of the TLS Keying Material Exporters
> defined in [RFC5705] to derive the session_key_seed.  The label used in the
> derivation is "EXPORTER: teap session key seed".  The length of the session
> key seed material is 40 octets.  *No context data is used in the export
> process.*"
>
> The change of moving the type-code from the context to the label was made
> based on your review (comments from Martin) and the fact that some
> libraries such as wolfssl don't support passing a context (so far). See:
> https://w1.fi/cgit/hostap/tree/src/crypto/tls_wolfssl.c#n1996
>
[Joe] If this implements the derivation RFC 5216.  It's not clear that
function will give you the right output with TLS 1.3 since we are now using
exporters.  Perhaps they provide an exporter interface which should be used
instead.

Personally, I think including the method byte in the context is a bit less
error prone and straight forward then including it in the label.


>
> With respect to the "commitment message", I thought we had a discussion
> that revealed that the mechanism in the -13 could not fulfil its stated
> purpose, and that also called into question whether that stated purpose was
> actually the right thing that the protocol needed.  My understanding,
> therefore, was that the TLS WG could not contribute further insight until
> there was a revised proposal from people who understand the needs of the
> EAP-TLS protocol from TLS that would both satisfy the needs of EAP and
> actually be achievable.
>
>
>   We have multiple inter-operable implementations which have implemented 
> draft-13.  That work over the last few months have resulted in implementors 
> making plans to do beta testing in the next few weeks.  Those plans have been 
> put on indefinite hold, due to the recent request for changes.
>
>   I understand getting feedback from the TLS WG is useful.  But I would 
> prefer to have consensus on a *solution*. Right now, we just have a series of 
> proposed changes, with little to no discussion.
>
> I think this is becaues the TLS WG members (in aggregate) do not have a
> clear picture of what property or properties EAP-TLS will require from TLS
> that led to the need for an additional message when using TLS 1.3 as
> opposed to the RFC 5216 case with TLS 1.2.  The prospect of an
> "authenticated signal from TLS to EAP-TLS that the authentication completed
> successfully" was mentioned, but I did not have the sense that there was

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

[Joseph Salowey]

HI Alan,

THanks for this message, comments inline below:

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.e. there would be no TLS layer signalling for the following situations:
>
>bad_certificate,  unsupported_certificate,  certificate_revoked,
> certificate_expired, certificate_unknown,  illegal_parameter, unknown_ca,
> access_denied, etc
>
>   This limitation would be an unmitigated disaster for EAP-TLS.  Those
> messages are required by people deploying EAP-TLS.  Without those messages,
> it will be near impossible to debug configuration issues.
>
>   As a result, we cannot use CloseNotify to signal "no more handshake
> messages" from the server.
>
>   There is a related issue, in that TLS 1.3 separates Session Tickets from
> TLS handshakes.  So it's still possible for the EAP state machine to send a
> 0x00 octet, and then the TLS state machines sends that *before* a Session
> Ticket.
>
>   In addition, RFC 8446 Figure 1 shows that application data can be sent
> by the server to the client, *before* the client certificate is sent to the
> server.  So sending this octet in EAP-TLS does not prove that the client
> certificate has been validated.
>
> DISCUSS: the EAP-TLS draft should explain that the 0x00 byte is NOT a
> positive signal of either "finished TLS", or "successful authentication".
>
> [Joe] It would be good to be clear about the purpose of the message.


> DISCUSS: the EAP-TLS draft should also explain that session tickets may be
> sent either before or after the 0x00 octet.  Does the packet flow look any
> different for the two cases?  If so, what does that mean?
>
> [Joe] I believe the flow of the message flights would be the same, but the
on-the-wire format of those flights could be reversed.  I don't think this
will necessarily cause a problem since the application data is consumed by
the EAP TLS and the NewSessionTicket is consumed by TLS,  However I think
the draft should be clear that this can happen.


> DISCUSS: We have interoperable implementations of -13.  Does this mean
> that the EAP state machines *implicitly* work with the TLS state machines?
> There is no *explicit* requirement in the draft about ordering, and no
> discussion thereof.  I suspect that this means the implementations work in
> part by accident, instead of by design.  So updates to TLS libraries *may*
> break EAP-TLS.  It would be best to make any assumptions explicit.  And /
> or to recommend to implementors that they be flexible with respect to
> changing order of the 0x00 octet vs session tickets.
>
> [Joe] Yes we should be clear about this.


>
>   In situations where resumption is not needed, figure 1 of
> https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-13 is correct.
> There are 3.5 rounds, which is about as low as possible.  Adding resumption
> here would *increase* there number of rounds to 4.5, which is worse!
>
> DISCUSS: the EAP-TLS draft Section 2.1.1 should be updated to note that
> this examples does not include Session Tickets.  Section 2.1.2 should be
> updated to note that there are more rounds than for the previous section.
>
>
[Joe] Yes.  It might be helpful to say that the commitment message may be
sent before or after the client authentication is verified, but in the case
that resumption is used it will always be after.


>
>   In situations where the certificate chain is longer, the initial
> authentication will be >=4.5 round trips, and session tickets are perhaps
> more useful.
>
> DISCUSS: the EAP-TLS draft s

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

[Jorge Vergara]

>>DISCUSS: We have interoperable implementations of -13.  Does this mean that 
>>the EAP state machines *implicitly* work with the TLS state machines?  There 
>>is no *explicit* requirement in the draft about ordering, and no discussion 
>>thereof.  I suspect that this means the implementations work in part by 
>>accident, instead of by design.  So updates to TLS libraries *may* break 
>>EAP-TLS.  It would be best to make any assumptions explicit.  And / or to 
>>recommend to implementors that they be flexible with respect to changing 
>>order of the 0x00 octet vs session tickets.
>[Joe] Yes we should be clear about this.
[Jorge] My only recommendation would be to wordsmith this part of draft-13 
found in section 2.5. I am not a good wordsmith but I see potential confusion 
here:
>After sending the Commitment Message, the EAP-TLS
>   server may only send an EAP-Success, an EAP-Failure, or an EAP-
>   Request with a TLS Alert Message.

[Jorge] The diagrams in the draft mostly imply that the commitment message 
being the last thing sent, after any NewSessionTicket. As stated, this is 
problematic since the TLS stack may re-order these, and the NewSessionTicket 
may have to come in another EAP-TLS fragment entirely if the combined message 
ends up crossing a fragment boundary.

In my mind, it is obvious that the rest of the EAP-TLS packet should be 
processed so that the EAP-TLS client can correctly receive the NewSessionTicket 
and any other handshake data that may have been in this final message. However, 
once that complete EAP-TLS packet is processed, the next message from the 
server should indeed be an EAP-Success, EAP-Failure, or EAP-Request with a TLS 
Alert Message as draft-13 indicates.

This is currently how the Windows client implementation operates, but it is 
mostly by chance. If we made the full processing of the EAP-TLS packet 
explicit, then I think this would resolve the concerns around ordering here.

Jorge Vergara

From: Emu  On Behalf Of Joseph Salowey
Sent: Friday, January 29, 2021 2:00 PM
To: Alan DeKok 
Cc: EMU WG ; Benjamin Kaduk ; Martin Thomson 
;  
Subject: Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on 
draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

HI Alan,

THanks for this message, comments inline below:

On Fri, Jan 29, 2021 at 12:02 PM Alan DeKok 
mailto:al...@deployingradius.com>> 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.e. there would be no TLS layer signalling for the following situations:

   bad_certificate,  unsupported_certificate,  certificate_revoked,
certificate_expired, certificate_unknown,  illegal_parameter, unknown_ca,
access_denied, etc

  This limitation would be an unmitigated disaster for EAP-TLS.  Those messages 
are required by people deploying EAP-TLS.  Without those messages, it will be 
near impossible to debug configuration issues.

  As a result, we cannot use CloseNotify to signal "no more handshake messages" 
from the server.

  There is a related issue, in that TLS 1.3 separates Session Tickets from TLS 
handshakes.  So it's still possible for the EAP state machine to send a 0x00 
octet, and then the TLS state machines sends that 

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

[David Benjamin]

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
.

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

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 in the instantiation function. It also
   configures settings to send. This all happens at the same time as
   existing ALPN setup.
   - The dispatcher runs the TLS handshake and gets an ALPN protocol as
   before, plus now an ALPS value.
   - The dispatcher instantiates the protocol as before, but if ALPS was
   negotiated, also passes a byte string to the ALPS-aware handler. Note the
   extension ensures this can only happen if the protocol was configured as
   ALPS-aware above.

The protocol acts accordingly. If ALPS was negotiated, HTTP/2 would apply
the received settings to the initial peer state. It also knows the initial
local state is different and can skip sending some values. This is added
logic to HTTP/2, but I think it’s fairly minimal. (And we can certainly
figure out the exact details that would work best.) It even has precedent
in the HTTP Upgrade path
 for “http”
URLs, so it's not even really new. Also note that all this happens before
any of the usual application I/O. (I wasn't sure what you meant by "timing
issues". Could you ela