Re: [TLS] Ticket request PR#20
>Declining this comes across hostile to me. I read the objections to
"only {0, 0} means zero" as a blocking counter-measure against the
deferred discussion, and not a material objection on the merits. :-(
Sadly, I concur with Viktor.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Ticket request PR#20
On Fri, May 01, 2020 at 02:39:58PM -0400, Viktor Dukhovni wrote:
> On Fri, May 01, 2020 at 11:18:58AM -0700, Benjamin Kaduk wrote:
>
> > > Declining this comes across hostile to me. I read the objections to
> > > "only {0, 0} means zero" as a blocking counter-measure against the
> > > deferred discussion, and not a material objection on the merits. :-(
> >
> > I don't think it's right to say that "only {0,0} means zero" -- after all,
> > this is a *request*, not a command from the client to the server.
>
> And yet, RFC 8446 C.4 says servers SHOULD always send at least one, and
> so this draft is modifying that to say that it is now "OK" to sometimes
> send no tickets based on the applicable counter. All I am asking for is
> that the "OK" condition be made more strict, requiring both counters to
> zero before C.4 is overriden.
I don't see how this draft is modifying that SHOULD -- SHOULD is for cases
where "do this if you don't know any better, but in some circumstances
doing the other thing is okay". I see this draft as defining a mechanism
to convey information from client to server, so that the server can know
whether it's one of those "some circumstances" when "doing the other thing
is okay". But that doesn't modify the SHOULD, and it's still up to the server.
> The server can still start WW-III upong seeing the extension, but that
> does not preclude clarity about the *intended* meaning. That's what
> the MUSTs/SHOULDs/MAYs etc. are for.
I actually think that in this case prose is going to be better at conveying
the intended meaning than normative keywords will, but should probably
refrain from commenting further until I actually do the AD Evaluation.
-Ben
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
[TLS] Publication has been requested for draft-ietf-tls-ticketrequests-05
Sean Turner has requested publication of draft-ietf-tls-ticketrequests-05 as Proposed Standard on behalf of the TLS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Ticket request PR#20
On Fri, May 01, 2020 at 11:18:58AM -0700, Benjamin Kaduk wrote:
> > Declining this comes across hostile to me. I read the objections to
> > "only {0, 0} means zero" as a blocking counter-measure against the
> > deferred discussion, and not a material objection on the merits. :-(
>
> I don't think it's right to say that "only {0,0} means zero" -- after all,
> this is a *request*, not a command from the client to the server.
And yet, RFC 8446 C.4 says servers SHOULD always send at least one, and
so this draft is modifying that to say that it is now "OK" to sometimes
send no tickets based on the applicable counter. All I am asking for is
that the "OK" condition be made more strict, requiring both counters to
zero before C.4 is overriden.
The server can still start WW-III upong seeing the extension, but that
does not preclude clarity about the *intended* meaning. That's what
the MUSTs/SHOULDs/MAYs etc. are for.
--
Viktor.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Ticket request PR#20
Hi Viktor,
On Fri, May 01, 2020 at 02:11:31PM -0400, Viktor Dukhovni wrote:
> On Fri, May 01, 2020 at 01:03:58PM -0400, Sean Turner wrote:
>
> > We recommend that PR#20 be closed and we will progress the draft to
> > Ben for his AD review. The suggested text is not strictly needed. As
> > the name of the draft suggests, the client’s ticket requests are just
> > that a request for tickets. The server is free to do whatever it wants
> > with the request.
>
> This is unfortunate, because there's an opportunity here to specify
> an extensible extension that could later be refined to support
> reuse at negligible cost to the "complexity" of the specification,
> indeed all the server has to do is issue at least one ticket like
> it always did, unless both counters are zero.
>
> I've agreed to defer actual consideration of reuse to a separate draft,
> but this preëmptively shuts the door on getting that done, without
> requiring a second largely redundant extension that would have to modify
> the meaning of {0,1} to make the "1" be "as needed". Now server that
> (hypothetically) are willing to support reuse will have to consider the
> interplay of two separate related extensions, which is definitely more
> complex.
>
> Declining this comes across hostile to me. I read the objections to
> "only {0, 0} means zero" as a blocking counter-measure against the
> deferred discussion, and not a material objection on the merits. :-(
I don't think it's right to say that "only {0,0} means zero" -- after all,
this is a *request*, not a command from the client to the server.
In particular, I see it as an indication of what the client wants in order
to meet the client's policy for (non-)reuse, but when the server's policy
is different, the server can and should diverge from the client's request.
This divergence can occur in either direction (more or fewer tickets issued).
Since the signal we're sending is merely advisory, it seems more prudent
to leave discussion of what a server should do when it receives specific
values as guidance for what factors a server logic should take into account
rather than trying to assign specific semantics to pairs of values that are
advisory in the first place. I think what people are objecting to is
trying to assign precise semantics to specific pairs of values when the
individual values themselves do not have such precise semantics.
I would need to go and re-read the text to be sure (and I guess I'll have
to when it gets to me for AD evaluation), but expect that some discussion
of how client policy can mismatch with server policy to be appropriate;
I expect to have more concrete text suggestions as part of my AD review.
Thanks,
Ben
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS Export Channel Binding
On Fri, May 1, 2020, at 14:08, Jonathan Hoyland wrote: > Maybe I'm missing something, but I don't see what your draft adds? If > someone wants to construct a channel binding then they agree with > their peer on a context and a label, and use that to construct an > exporter key. The draft just registers a method of using it with the IANA Channel Binding Types registry so that you can negotiate and use exported keying material in eg. SCRAM based SASL auth. Right now if I wanted to use EKM for channel binding, what would I negotiate (ie. what would I set the p field of a gs2 header to in SASL based auth?) > Is the idea to reserve the string for some specific use? If so, then > the suggested string is far to general, as it describes _any_ use of > the interface. Yes, that's the idea. This registers the "tls-exporter" channel binding type in the registry, and the label EXPORTER-Channel-Binding to use with it. This is supposed to be a generic channel binding type that can be used to negotiate channel binding when multiple are available, eg. if the server supports both tls-unique (the last TLS finished message) and exporter data, we need an identifier to decide that we want to use exporter data. That also means having a label that we can associate with this context. I'd be happy to change the name if the consensus is that this is too general, but I didn't think it made sense to make this SASL or specific. —Sam ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Ticket request PR#20
On Fri, May 01, 2020 at 01:03:58PM -0400, Sean Turner wrote:
> We recommend that PR#20 be closed and we will progress the draft to
> Ben for his AD review. The suggested text is not strictly needed. As
> the name of the draft suggests, the client’s ticket requests are just
> that a request for tickets. The server is free to do whatever it wants
> with the request.
This is unfortunate, because there's an opportunity here to specify
an extensible extension that could later be refined to support
reuse at negligible cost to the "complexity" of the specification,
indeed all the server has to do is issue at least one ticket like
it always did, unless both counters are zero.
I've agreed to defer actual consideration of reuse to a separate draft,
but this preëmptively shuts the door on getting that done, without
requiring a second largely redundant extension that would have to modify
the meaning of {0,1} to make the "1" be "as needed". Now server that
(hypothetically) are willing to support reuse will have to consider the
interplay of two separate related extensions, which is definitely more
complex.
Declining this comes across hostile to me. I read the objections to
"only {0, 0} means zero" as a blocking counter-measure against the
deferred discussion, and not a material objection on the merits. :-(
--
Viktor.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS Export Channel Binding
Hi Sam, I think the idea is that any unique¹ exporter _is_ an RFC 5056-compliant channel binding. Maybe I'm missing something, but I don't see what your draft adds? If someone wants to construct a channel binding then they agree with their peer on a context and a label, and use that to construct an exporter key. If they mix that key into the key schedule of some other protocol then that second protocol is bound to the TLS session². If they want to pick the label "EXPORTER-Channel-Binding" and the empty context, then that's already covered by the spec. Is the idea to reserve the string for some specific use? If so, then the suggested string is far to general, as it describes _any_ use of the interface. What do you see as the difference between an Exporter key and a channel binding? Regards, Jonathan 1. I'm assuming an exporter is unique within a given TLS session iff the given label and context are unique. 2. Unless the second protocol does something stupid like leak the TLS session's master secret. On Fri, 1 May 2020 at 17:08, Sam Whited wrote: > Hi Jonathan, > > On Fri, May 1, 2020, at 12:00, Jonathan Hoyland wrote: > > I believe TLS Exporters are what you are looking for. > > https://www.rfc-editor.org/rfc/rfc8446.html#section-7.5 > > Thanks for the follow up. That is indeed what the channel binding type > I've created uses. Would the TLS working group be interested in > standardizing such a document? > > I've gone ahead and uploaded my initial draft that I threw together here > in case you're interested: > > > https://datatracker.ietf.org/doc/draft-whited-tls-channel-bindings-for-tls13/ > > —Sam > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Ticket request PR#20
All, We recommend that PR#20 be closed and we will progress the draft to Ben for his AD review. The suggested text is not strictly needed. As the name of the draft suggests, the client’s ticket requests are just that a request for tickets. The server is free to do whatever it wants with the request. spt (for Joe and Sean) > On Apr 19, 2020, at 18:23, Viktor Dukhovni wrote: > > I uploaded a small pull request for the ticket request draft: > >https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/20 > > it stipulates that servers SHOULD send at least one ticket unless *both* > counters are zero. A client willing to accept tickets for either of the > two handshake types is capable of accepting a ticket for the other. > > Yes, this leaves the door open to later define (or not) special > semantics for the zero value to be used between mutually consenting > clients and servers. > > -- >Viktor. > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS Export Channel Binding
Hi Jonathan, On Fri, May 1, 2020, at 12:00, Jonathan Hoyland wrote: > I believe TLS Exporters are what you are looking for. > https://www.rfc-editor.org/rfc/rfc8446.html#section-7.5 Thanks for the follow up. That is indeed what the channel binding type I've created uses. Would the TLS working group be interested in standardizing such a document? I've gone ahead and uploaded my initial draft that I threw together here in case you're interested: https://datatracker.ietf.org/doc/draft-whited-tls-channel-bindings-for-tls13/ —Sam ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS Export Channel Binding
Hi Sam, I believe TLS Exporters are what you are looking for. https://www.rfc-editor.org/rfc/rfc8446.html#section-7.5 Exporters allow you to produce a key that is a bound to a particular channel i.e. TLS session. Regards, Jonathan On Fri, 1 May 2020 at 15:13, Sam Whited wrote: > Hi all, > > I'm in need of a channel binding mechanism that works for TLS 1.3, but > as far as I can tell there isn't one. I've thrown together a document > defining a mechanism using RFC 5705 which I believe meets all of the > requirements for good channel binding. > > Is anyone aware of work already being done in this area (I saw the token > binding stuff, but that's a lot more complicated and browser-focused > than a simple channel binding mechanism and work appears to have > stalled), and if not would the TLS WG be interested in such a document? > > Thanks, > Sam > > P.S. Note that I also sent this question to the KITTEN WG because I > wasn't sure where this would belong. > > -- > Sam Whited > > ___ > 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] TLS Export Channel Binding
Hi all, I'm in need of a channel binding mechanism that works for TLS 1.3, but as far as I can tell there isn't one. I've thrown together a document defining a mechanism using RFC 5705 which I believe meets all of the requirements for good channel binding. Is anyone aware of work already being done in this area (I saw the token binding stuff, but that's a lot more complicated and browser-focused than a simple channel binding mechanism and work appears to have stalled), and if not would the TLS WG be interested in such a document? Thanks, Sam P.S. Note that I also sent this question to the KITTEN WG because I wasn't sure where this would belong. -- Sam Whited ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Editorial Errata Reported] RFC8446 (6120)
I think the point here is that the "transport" isn't a "data stream", the transport is what the data stream is delivered over. I agree that the intended meaning is clear, but the text as written isn't correct, and if the draft's being corrected anyway this should be corrected too. William -Original Message- From: TLS On Behalf Of Peter Wu Sent: Friday, May 1, 2020 5:35 AM To: RFC Errata System Cc: r...@cert.org; sean+i...@sn3rd.com; ka...@mit.edu; tls@ietf.org Subject: [EXT] Re: [TLS] [Editorial Errata Reported] RFC8446 (6120) Hi, In what way is the old writing ambiguous? The semantics of that text is correct. If someone wants to run the TLS protocol on paper as "transport", it would still maintain the same guarantees. And "paper" is arguably not a transport protocol or "stream delivery service". I suggest to reject this change. Kind regards, Peter On Fri, Apr 24, 2020 at 02:05:04AM -0700, RFC Errata System wrote: > The following errata report has been submitted for RFC8446, > "The Transport Layer Security (TLS) Protocol Version 1.3". > > -- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6120 > > -- > Type: Editorial > Reported by: Ben Smyth > > Section: 1 > > Original Text > - > the underlying transport is a reliable, in-order data stream > > > > Corrected Text > -- > the underlying transport layer is a reliable, in-order stream delivery service > > or > > the underlying transport protocol is a reliable, in-order stream delivery > service > > or similar > > Notes > - > Similar elsewhere > > Instructions: > - > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -- > RFC8446 (draft-ietf-tls-tls13-28) > -- > Title : The Transport Layer Security (TLS) Protocol Version 1.3 > Publication Date: August 2018 > Author(s) : E. Rescorla > Category: PROPOSED STANDARD > Source : Transport Layer Security > Area: Security > Stream : IETF > Verifying Party : IESG > > ___ > 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] [Editorial Errata Reported] RFC8446 (6127)
>From the perspective of someone who spends a lot of his time writing/editing >standards, I agree with the Errata and disagree with Peter's comment. If >"abort" and "terminate" mean the same thing, that should be made clear. Words >in standards need to have specific definitions. A developer who reads "abort" >in one place and "terminate" in another might reasonably assume that because >two different words are used, two different things are meant, and burn >unnecessary cycles working out what the difference is. William -Original Message- From: TLS On Behalf Of Peter Wu Sent: Friday, May 1, 2020 7:07 AM To: RFC Errata System Cc: r...@cert.org; sean+i...@sn3rd.com; ka...@mit.edu; tls@ietf.org Subject: [EXT] Re: [TLS] [Editorial Errata Reported] RFC8446 (6127) How could this affect the readers comprehension? This is not an editorial issue in as defined at https://www.rfc-editor.org/errata-definitions/ >From the context it is often clear what "abort" or "terminate" means. An enumeration of the first occurrences in the document: - "A failure of the handshake or other protocol error triggers the termination of the connection, optionally preceded by an alert message (Section 6)." - "the server MUST abort the handshake with an appropriate alert." - "MUST abort the handshake with an "unexpected_message" alert." I suggest rejecting this report. Kind regards, Peter On Fri, Apr 24, 2020 at 02:55:57AM -0700, RFC Errata System wrote: > The following errata report has been submitted for RFC8446, > "The Transport Layer Security (TLS) Protocol Version 1.3". > > -- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6128 > > -- > Type: Editorial > Reported by: Ben Smyth > > Section: GLOBAL > > Original Text > - > terminate and abort are used interchangeable, but this isn't explained until > after such use. > > In Section 6.2, we have: In the rest of this specification, when the phrases > "terminate the connection" and "abort the handshake" are used without a > specific alert it means that the implementation SHOULD send the alert > indicated by the > descriptions below. > > Corrected Text > -- > Perhaps explain terminology earlier. At the very least, in Section 6.2, open > the above sentence with "Throughout this specification" > > > > Notes > - > > > Instructions: > - > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -- > RFC8446 (draft-ietf-tls-tls13-28) > -- > Title : The Transport Layer Security (TLS) Protocol Version 1.3 > Publication Date: August 2018 > Author(s) : E. Rescorla > Category: PROPOSED STANDARD > Source : Transport Layer Security > Area: Security > Stream : IETF > Verifying Party : IESG > > ___ > 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] [Editorial Errata Reported] RFC8446 (6127)
How could this affect the readers comprehension? This is not an editorial issue in as defined at https://www.rfc-editor.org/errata-definitions/ >From the context it is often clear what "abort" or "terminate" means. An enumeration of the first occurrences in the document: - "A failure of the handshake or other protocol error triggers the termination of the connection, optionally preceded by an alert message (Section 6)." - "the server MUST abort the handshake with an appropriate alert." - "MUST abort the handshake with an "unexpected_message" alert." I suggest rejecting this report. Kind regards, Peter On Fri, Apr 24, 2020 at 02:55:57AM -0700, RFC Errata System wrote: > The following errata report has been submitted for RFC8446, > "The Transport Layer Security (TLS) Protocol Version 1.3". > > -- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6128 > > -- > Type: Editorial > Reported by: Ben Smyth > > Section: GLOBAL > > Original Text > - > terminate and abort are used interchangeable, but this isn't explained until > after such use. > > In Section 6.2, we have: In the rest of this specification, when the phrases > "terminate the connection" and "abort the handshake" are used without a > specific alert it means that the implementation SHOULD send the alert > indicated by the > descriptions below. > > Corrected Text > -- > Perhaps explain terminology earlier. At the very least, in Section 6.2, open > the above sentence with "Throughout this specification" > > > > Notes > - > > > Instructions: > - > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -- > RFC8446 (draft-ietf-tls-tls13-28) > -- > Title : The Transport Layer Security (TLS) Protocol Version 1.3 > Publication Date: August 2018 > Author(s) : E. Rescorla > Category: PROPOSED STANDARD > Source : Transport Layer Security > Area: Security > Stream : IETF > Verifying Party : IESG > > ___ > 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] [Editorial Errata Reported] RFC8446 (6127)
The current section describes what a client should do when it faces a HRR, and the referenced bullet point specifies how the HRR "key_share" extension should be processed. The errata suggests "clarifying" that point by adding: > Note: A "key_share" extension may not be supplied in a > HelloRetryRequest message when a server receives an "early_data" > (Section 4.2.10). I interpret it as: If the client sends an "early_data" extension in its Client Hello, then the server responding with a HelloRetryRequest MAY include or omit the "key_share" extension in the HRR. That is not a result that is unique to the presence of the "early_data". Perhaps you misinterpreted the second bullet point in https://tools.ietf.org/html/rfc8446#page-54 This report does not fix an error, and it adds only more confusion. I suggest rejecting it. Kind regards, Peter On Fri, Apr 24, 2020 at 02:49:54AM -0700, RFC Errata System wrote: > The following errata report has been submitted for RFC8446, > "The Transport Layer Security (TLS) Protocol Version 1.3". > > -- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6127 > > -- > Type: Editorial > Reported by: Ben Smyth > > Section: 4.1.2. > > Original Text > - > If a "key_share" extension was supplied in the HelloRetryRequest, > replacing the list of shares with a list containing a single > KeyShareEntry from the indicated group. > > Corrected Text > -- > If a "key_share" extension was supplied in the HelloRetryRequest, > replacing the list of shares with a list containing a single > KeyShareEntry from the indicated group. Note: A "key_share" > extension may not be supplied in a HelloRetryRequest message > when a server receives an "early_data" (Section 4.2.10). > > Notes > - > > > Instructions: > - > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -- > RFC8446 (draft-ietf-tls-tls13-28) > -- > Title : The Transport Layer Security (TLS) Protocol Version 1.3 > Publication Date: August 2018 > Author(s) : E. Rescorla > Category: PROPOSED STANDARD > Source : Transport Layer Security > Area: Security > Stream : IETF > Verifying Party : IESG > > ___ > 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] [Editorial Errata Reported] RFC8446 (6125)
Dear Peter, On Fri, 1 May 2020 at 12:30, Peter Wu wrote: > Do you have a specific sentence that caused confusion for you? Both > "out-of-band" and "external" can be used interchangeably. > Getting to grips with TLS 1.3 has been challenging for me! The use of synonyms made it more difficult. I hope that the reports I have submitted will aid others in understanding the specification. Longer-term they may even aid the development for future documents. Many of the reports are minor, others are preventing me from fully understanding the specification, and several may highlight minor technical issues. They all came about whilst writing a manual for TLS ( https://bensmyth.com/publications/2019-TLS-tutorial/), which I'm currently extending. Since the reports are based on my private notes, I thought sharing them (via reports) would be useful. Best regards, Ben ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Editorial Errata Reported] RFC8446 (6126)
There is no error here, clarifications such as these which can already be correctly interpreted by a careful reader should probably not be reported through the errata system. >From https://www.rfc-editor.org/errata-definitions/ Type Name: Editorial Description: "a spelling, grammar, punctuation, or syntax error that does not affect the technical meaning" I suggest rejecting this report. Kind regards, Peter On Fri, Apr 24, 2020 at 02:41:19AM -0700, RFC Errata System wrote: > The following errata report has been submitted for RFC8446, > "The Transport Layer Security (TLS) Protocol Version 1.3". > > -- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6126 > > -- > Type: Editorial > Reported by: Ben Smyth > > Section: 4.1.1 > > Original Text > - > Note that if the PSK can be used without (EC)DHE, then > non-overlap in the "supported_groups" parameters need not be fatal, > as it is in the non-PSK case discussed in the previous paragraph. > > Corrected Text > -- > Note that if the PSK can be used without (EC)DHE, then > non-overlap in the "supported_groups" parameters need not be fatal, > as it is in the non-PSK case discussed in the previous paragraph, > because PSK-only key exchange mode does not need supported_groups. > > Notes > - > If "the PSK can be used without (EC)DHE", then PSK-only key exchange mode can > be used, which doesn't require supported_groups. This is perhaps worthy of > explanation. > > Instructions: > - > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -- > RFC8446 (draft-ietf-tls-tls13-28) > -- > Title : The Transport Layer Security (TLS) Protocol Version 1.3 > Publication Date: August 2018 > Author(s) : E. Rescorla > Category: PROPOSED STANDARD > Source : Transport Layer Security > Area: Security > Stream : IETF > Verifying Party : IESG > > ___ > 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] [Editorial Errata Reported] RFC8446 (6125)
Hi Ben, Do you have a specific sentence that caused confusion for you? Both "out-of-band" and "external" can be used interchangeably. What is unclear about https://tools.ietf.org/html/rfc8446#section-2.2 for example? If you are interested in use of external PSKs, I suggest following this work: https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer This errat report lacks context, and even if accepted, it should probably have been a new document. I suggest rejecting it. Kind regards, Peter On Fri, Apr 24, 2020 at 02:22:12AM -0700, RFC Errata System wrote: > The following errata report has been submitted for RFC8446, > "The Transport Layer Security (TLS) Protocol Version 1.3". > > -- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6125 > > -- > Type: Editorial > Reported by: Ben Smyth > > Section: GLOBAL > > Original Text > - > PSKs are referred to as out-of-band and external > > Corrected Text > -- > Referring to PSKs as either out-of-band xor external would help at least one > reader > > Notes > - > > > Instructions: > - > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -- > RFC8446 (draft-ietf-tls-tls13-28) > -- > Title : The Transport Layer Security (TLS) Protocol Version 1.3 > Publication Date: August 2018 > Author(s) : E. Rescorla > Category: PROPOSED STANDARD > Source : Transport Layer Security > Area: Security > Stream : IETF > Verifying Party : IESG > > ___ > 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] [Editorial Errata Reported] RFC8446 (6124)
The change is in "a list of symmetric cipher/HKDF hash pairs" and Ben suggests changing "HKDF hash" to either "Hash algorithm" or "Hash algorithm (to be used with HKDF)". The hash is not just used for the HKDF, but also for Transcript-Hash, so if this had to be changed, I would vote for "Hash algorithm". Note that "HKDF hash" is used consistently in one other place, so that might have to be changed as well. Additionally, Section 7.1 defined relates both the three "hash" functions: The Hash function used by Transcript-Hash and HKDF is the cipher suite hash algorithm. This is a minor update to a text that was not incorrect. Not sure whether this was really worth an errata report. Kind regards, Peter On Fri, Apr 24, 2020 at 02:18:39AM -0700, RFC Errata System wrote: > The following errata report has been submitted for RFC8446, > "The Transport Layer Security (TLS) Protocol Version 1.3". > > -- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6124 > > -- > Type: Editorial > Reported by: Ben Smyth > > Section: 2 > > Original Text > - >In the Key Exchange phase, the client sends the ClientHello > >(Section 4.1.2) message, which contains a random nonce > >(ClientHello.random); its offered protocol versions; a list of > >symmetric cipher/HKDF hash pairs; either a set of Diffie-Hellman key > >shares (in the "key_share" (Section 4.2.8) extension), a set of > >pre-shared key labels (in the "pre_shared_key" (Section 4.2.11) > >extension), or both; and potentially additional extensions. > > Corrected Text > -- >In the Key Exchange phase, the client sends the ClientHello > >(Section 4.1.2) message, which contains a random nonce > >(ClientHello.random); its offered protocol versions; a list of > >symmetric cipher/Hash algorithm pairs; either a set of Diffie-Hellman key > >shares (in the "key_share" (Section 4.2.8) extension), a set of > >pre-shared key labels (in the "pre_shared_key" (Section 4.2.11) > >extension), or both; and potentially additional extensions. > > or > >In the Key Exchange phase, the client sends the ClientHello > >(Section 4.1.2) message, which contains a random nonce > >(ClientHello.random); its offered protocol versions; a list of > >symmetric cipher/Hash algorithm (to be used with HKDF) pairs; either a set > of Diffie-Hellman key >shares (in the "key_share" (Section 4.2.8) extension), a set of > >pre-shared key labels (in the "pre_shared_key" (Section 4.2.11) > >extension), or both; and potentially additional extensions. > > Notes > - > > > Instructions: > - > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -- > RFC8446 (draft-ietf-tls-tls13-28) > -- > Title : The Transport Layer Security (TLS) Protocol Version 1.3 > Publication Date: August 2018 > Author(s) : E. Rescorla > Category: PROPOSED STANDARD > Source : Transport Layer Security > Area: Security > Stream : IETF > Verifying Party : IESG > > ___ > 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] [Technical Errata Reported] RFC8446 (6123)
Hi,
Throughout the document, it is pretty clear what optionality refers to:
1. Introduction
[...]
- Authentication: The server side of the channel is always
authenticated; the client side is optionally authenticated.
and from the same Protocol Overview section, 2 pages later:
- Authentication: Authenticate the server (and, optionally, the
client) and provide key confirmation and handshake integrity.
The "optionally authenticate each other" text appears to have been
carried over from TLS 1.2 and before where anonymous key exchanges were
still a thing.
I don't think there is any misinterpretation possible from someone
reading the whole section and I like the current conciseness. A longer,
but technically more accurate version could be:
[..], authenticate the server to the client, optionally authenticate
the client to the server, [..]
I suggest (reluctantly) accepting this ("Held for Document Update") or
rejecting it.
Kind regards,
Peter
On Fri, Apr 24, 2020 at 02:15:22AM -0700, RFC Errata System wrote:
> The following errata report has been submitted for RFC8446,
> "The Transport Layer Security (TLS) Protocol Version 1.3".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6123
>
> --
> Type: Technical
> Reported by: Ben Smyth
>
> Section: 2
>
> Original Text
> -
> The handshake protocol allows peers to negotiate a protocol version, select
> cryptographic algorithms, optionally authenticate each other, and establish
> shared secret keying material.
>
> Corrected Text
> --
>
>
> Notes
> -
> Only client authentication is optional (albeit, server authentication is
> implicit for PSK-only key exchange mode)
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --
> RFC8446 (draft-ietf-tls-tls13-28)
> --
> Title : The Transport Layer Security (TLS) Protocol Version 1.3
> Publication Date: August 2018
> Author(s) : E. Rescorla
> Category: PROPOSED STANDARD
> Source : Transport Layer Security
> Area: Security
> Stream : IETF
> Verifying Party : IESG
>
> ___
> 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] [Editorial Errata Reported] RFC8446 (6122)
Hi, The original text was not wrong. Originally TLS 1.2 and before defined a PRF for key derivation, and there exist multiple instantiations with different hash functions (e.g. SHA-256 and SHA-384). So each instantiation could be considered a different function. Your suggested text can also be considered correct as there is only construction in TLS 1.2, but I don't think it is worth marking the text as in error. I suggest to reject this. Kind regards, Peter On Fri, Apr 24, 2020 at 02:08:11AM -0700, RFC Errata System wrote: > The following errata report has been submitted for RFC8446, > "The Transport Layer Security (TLS) Protocol Version 1.3". > > -- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6122 > > -- > Type: Editorial > Reported by: Ben Smyth > > Section: 1.2 > > Original Text > - > The key derivation functions have been redesigned. > > Corrected Text > -- > The key derivation function has been redesigned. > > Notes > - > > > Instructions: > - > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -- > RFC8446 (draft-ietf-tls-tls13-28) > -- > Title : The Transport Layer Security (TLS) Protocol Version 1.3 > Publication Date: August 2018 > Author(s) : E. Rescorla > Category: PROPOSED STANDARD > Source : Transport Layer Security > Area: Security > Stream : IETF > Verifying Party : IESG > > ___ > 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] Choice of Additional Data Computation
> > (*): Even if we optimize the CID away with cTLS the question about the > > security implications will surface again. > I think that cTLS is the answer to the size issue. But there, the rule tends > to be that removing from the wire doesn't also remove from the canonical > value that is processed by the stack, so we > might be able to send without a > CID, but re-insert the value before processing. As the canonical form, DTLS > always including the value seems fine to me. On: "the rule tends to be that removing from the wire doesn't also remove from the canonical value that is processed by the stack" I fully agree, and whether true or not, that's the reason why so far I thought that an AEAD that's agnostic of compression techniques and operates as-if there's always a full header on the wire, is more robust than what we have at the moment. Regarding re-introducing the explicit CID in DTLS 1.3: My impression so far was that DTLS 1.3 attempts to already incorporate some record compression ideas through the flexible header format, and I'd find it cleaner to either explore and use those ideas fully (including implicit CIDs, for example), or leave them for c[D]TLS entirely and stick to a single header format for DTLS 1.3. But that's subjective. Apart from that, thanks Martin for sharing the paper https://felixguenther.info/Q20_RC.pdf in the other thread, I think it might be useful for this thread, too. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Editorial Errata Reported] RFC8446 (6120)
Hi, In what way is the old writing ambiguous? The semantics of that text is correct. If someone wants to run the TLS protocol on paper as "transport", it would still maintain the same guarantees. And "paper" is arguably not a transport protocol or "stream delivery service". I suggest to reject this change. Kind regards, Peter On Fri, Apr 24, 2020 at 02:05:04AM -0700, RFC Errata System wrote: > The following errata report has been submitted for RFC8446, > "The Transport Layer Security (TLS) Protocol Version 1.3". > > -- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6120 > > -- > Type: Editorial > Reported by: Ben Smyth > > Section: 1 > > Original Text > - > the underlying transport is a reliable, in-order data stream > > > > Corrected Text > -- > the underlying transport layer is a reliable, in-order stream delivery service > > or > > the underlying transport protocol is a reliable, in-order stream delivery > service > > or similar > > Notes > - > Similar elsewhere > > Instructions: > - > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -- > RFC8446 (draft-ietf-tls-tls13-28) > -- > Title : The Transport Layer Security (TLS) Protocol Version 1.3 > Publication Date: August 2018 > Author(s) : E. Rescorla > Category: PROPOSED STANDARD > Source : Transport Layer Security > Area: Security > Stream : IETF > Verifying Party : IESG > > ___ > 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
