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:
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
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
> > (*): 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
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
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
>
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
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,
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
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
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
>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
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
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,
>
>
>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.
___
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
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
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
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
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
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
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
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
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
24 matches
Mail list logo
