Re: [TLS] [Editorial Errata Reported] RFC8446 (6120)

[William Whyte]

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)

[William Whyte]

>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] kicking off charter revision discussion

[William Whyte]

I’m happy to submit the draft as it stands. I think it’s covered by the 
recharter below under “maintain” the spec, though perhaps we should suggest 
that this is changed to “maintain and, as necessary, extend”.

Cheers,

William
On Oct 24, 2018, 8:20 PM -0400, Sean Turner , wrote:
> With the finalization of TLS 1.3 behind us, it is time to consider 
> rechartering the working group to address ongoing and emerging issues in this 
> space. Below is a proposal for the new charter text to get this discussion 
> going before we meet in Bangkok. We plan to have a 20 minute discussion 
> section on the charter in one of the upcoming TLS WG meeting sessions. If you 
> have objections to what is written, please raise them to the list; we will 
> track them with issues in the newly created GH repo [0]. If you feel 
> something is omitted, please also bring it to the list but also feel free to 
> suggest edits via issues/PRs in that repo.
>
> Thanks,
> Chris, Joe, and Sean
>
> [0] https://github.com/tlswg/wg-materials/tree/master/charter.
>
> Proposed Charter Text
>
> The TLS (Transport Layer Security) working group was established in 1996 to 
> standardize a 'transport layer' security protocol. The basis for the work was 
> SSL (Secure Socket Layer) v3.0 [RFC6101]. The TLS working group has completed 
> a series of specifications that describe the TLS protocol v1.0 [RFC2246], 
> v1.1 [RFC4346], v1.2 [RFC5346], and v1.3 [RFC8446], and DTLS (Datagram TLS) 
> v1.0 [RFC4347] and v1.2 [RFC6347], as well as extensions to the protocols and 
> ciphersuites.
>
> The working group aims to achieve three goals. First, to develop DTLS 1.3, in 
> a way that draws upon the design, analysis, and engineering effort put into 
> TLS 1.3. Specifically, the protocol should exhibit the following features, in 
> no particular order:
>
> - Encrypt as much of the handshake and datagram packets as
> possible to reduce the amount of observable data to both
> passive and active attackers.
> - Reduce handshake latency and aim for one roundtrip for a full
> handshake and one or zero roundtrip for repeated handshakes
> without compromising current security features.
> - Use cryptographic algorithms equivalent to those used in TLS 1.3.
>
> The second working group goal is to improve protocol extensibility, 
> usability, and deployability, e.g., GREASE, Delegated Credentials, 
> Certificate Compression, and Exported Authenticators. These working group 
> items will include a focus on privacy properties of (D)TLS, with a particular 
> emphasis on the following:
>
> - Encrypt the ClientHello SNI (Server Name Indication) and other
> application-sensitive extensions, such as
> ALPN (Applications-Layer Protocol Negotiation).
> - Identify and mitigate other (long-term) user tracking or fingerprinting
> vectors enabled by TLS deployments and implementations.
> - Consider additional privacy-preserving mechanisms, e.g., consistent
> application traffic padding.
> - Develop privacy-friendly profiles describing recommended usage of
> (D)TLS for generic use. Protocol-specific profiles are out of scope.
>
> The third goal is to maintain current and previous version of the (D)TLS 
> protocols as well as to specify general best practices for use of (D)TLS, 
> extensions to (D)TLS, and cipher suites. This includes recommendations as to 
> when a particular version should be deprecated. Changes or additions to older 
> versions of (D)TLS whether via extensions or ciphersuites are discouraged and 
> require significant justification to be taken on as work items.
>
> With these objectives in mind, the TLS WG will also place a priority in 
> minimizing gratuitous changes to (D)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] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates

[William Whyte]

Hi Ilari,

>> - The construction looks like it mixes different kinds of structures:
  1609.2 Data of type signed versus TLS 1.3 signature. I do not think
  this is cryptographically kosher. In fact, I think the call for
  "extreme care" for certain kinds of modifications from TLS 1.3
  specification appiles here.

>>  That is, with 1609.2 what is passed to actual raw signature is not
  TLS 1.3 signature structure, nor something compatible with it
  (the invariant part with dedicated context is only up to and
  including the zero separator). However, I do not think that
  changing the context and then hacking what comes afterwards
  (altough it seems cryptographically kosher) is a good idea for
  implemntation reasons.

You're right, it uses the 1609.2 data structure. The rationale is as
follows:

Software:

Most 1609.2 libraries offer only a high-level API for signing and
verification, where:

On signing: the input is the data, a handle for the key, and a set of
options, and the output is a 1609.2 signed data.

On verification: the input is the Ieee1609Dot2Data output by signing, the
certificate, and some options, and the output is either “valid” or an error
code.

As such, using a 1609Dot2Data in the Signature field doesn’t require any
software changes to 1609.2 libraries. It does require an additional change
to the TLS library, which is to check if a 1609.2 certificate is being used
and if so to send the Signature field to a 1609.2 verification engine
rather than a “raw” ECDSA verification engine, but the TLS library is being
changed anyway and this approach allows the changes to be confined to a
single codebase.

Philosophy:

1609.2 certificates are by intent more tightly coupled to the signing
mechanism than X.509 certificates. 1609.2 specifies consistency between a
certificate and the PDU that it signs in terms of validity period,
(optionally) geographic location, and application permissions (PSID and
SSP), and it would be unfortunate to create a setting in which they can be
less tightly coupled. In particular, since a certificate can contain more
than one PSID, it’s useful to state the PSID which the certificate holder
is intending to assert in a given context. The most natural way to do this
is to use an IEEE1609Dot2Data.

A rationale for continuing to use the raw signature field would be to make
the change to TLS as minimal as possible. This is a reasonable rationale,
but we would argue that allowing the signature format to depend on the
certificate type does not break the TLS model as much as allowing a
different entry point to 1609.2 cryptographic processing breaks the 1609.2
model. Since one or the other has to be changed, and since the TLS
implementation is being changed already, we prefer to keep the changes to
the TLS.

If it would help, we could add this rationale to the Security
Considerations section.

>> - Bleh: Hardcoding SHA-256 in place that requires a strong hash. One
  more place to mind if SHA-256 someday breaks. The hash looks
  extraneous too, as what needs to be signed is not long.

1609.2 currently only supports SHA-256 for message hashing -- it's
extensible, in that it has a hash algorithm identifier that can in
principle be extended with additional identifier values, but currently only
SHA-256 is defined for message hashing. The hardcoding of SHA-256 in this
draft should be read as informative text about a constraint that exists
anyway in 1609.2. If 1609.2 is extended to support additional hash
algorithms we'll circle back and change this part of this draft.

>> - Changing CV format with certificate format could create problems with
  existing TLS implmentations, as there is no precendent for such
  change. In fact, there even isn't an extension that changes that
  (and such extension would require very careful analysis).

I accept that this is a valid concern in general and complicates the TLS
signing/verification logic. As described above, we reluctantly decided that
this was a preferable approach to using raw signatures with 1609.2
certificates, because when you're using 1609.2 certificates it's because
you want the tighter binding to owner permissions that you get from 1609.2
and as such it's important to use 1609.2 certificates accompanied by the
1609.2 signed data structure. I don't think this is a direct security
concern, but I acknowledge that the additional complexity in TLS
implementations is regrettable.

>> And
  what about TLS 1.2, which does not use CV for server side, and has
  different format CV for client side?

I'll be honest, when I drafted this part of the document I was thinking
only about TLS 1.3. I don't have a strong feeling that 1609.2 certificates
should be usable in TLS 1.2. We'd be happy to take guidance about how this
could be integrated into TLS 1.2.

Note re the comment about existing implementations above that if you're
focusing on TLS 1.3, then there are fewer and less well-established
existing implementations than there are with TLS 1.2, so I

Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates

[William Whyte]

Hi Wang,

The 1609.2 certificate format consists of both explicit and implicit
certificates. The explicit certificates are in 1609.2 format, not in X.509
format.

Cheers,

William

On Mon, Aug 27, 2018 at 4:43 AM, Wang Haiguang <
wang.haiguang.shield...@huawei.com> wrote:

> Hi, Mounira
>
> Thanks for the clarification. That means both explicit and implicit
> certificates will be supported.
>
> Regards.
>
> Haiguang
>
> -Original Message-
> From: Mounira Msahli [mailto:mounira.msa...@telecom-paristech.fr]
> Sent: Monday, August 27, 2018 4:32 PM
> To: Wang Haiguang 
> Cc: Ilari Liusvaara ; tls 
> Subject: Re: TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2
> certificates
>
> Hi Wang,
>
> The purpose of the draft is to extend TLS 1.3 to support IEEE 1609.2/ETSI
> TS 103 097 certificates for authentication in addition to X.509 certificate
> and raw public keys.
>
> Kind Regards
> Mounira
>
>
>
> - Mail original -
> De: "Wang Haiguang" 
> À: "Mounira Msahli" , "Ilari
> Liusvaara" 
> Cc: "tls" 
> Envoyé: Lundi 27 Août 2018 03:44:28
> Objet: RE: TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2
> certificates
>
> Hi, Mounira
>
> Just for clarification.
>
> If I am not wrong, there are two types of certificates supported by
> 1609.2. One is the legacy X.509 certificate, the other is the implicit
> certificate.
>
> So for you draft submitted, you plan support both types of certificates or
> just one of them, i.e. the X.509 certificate.
>
> Best regards.
>
> Haiguang
>
> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Mounira Msahli
> Sent: Saturday, August 25, 2018 1:45 AM
> To: Ilari Liusvaara 
> Cc: tls 
> Subject: Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE
> 1609.2 certificates
>
>
> Thank you Ilari,
>
>
> In response to your comments below:
>
> - I did not see requirements where to place the end-entity certificate
> anywhere. I think most TLS code outright assumes that the end-entity
> certificate is the first one.
>
> >>> We will add it.
>
> - More generally, I did not see it specified how the certificate chain is
> laid out to the individual certficate fields (it is fairly obvious, but
> should still be specified).
> >>> We will specify it.
>
> - The examples could have multiple certificate types in ClientHello to
> more clearly show what is actually going on.
> >>> We will add examples with multiple certificate types in Client Hello
>
> - You should also specify use in TLS 1.2 in the same draft (or say that
> is prohibited). This is so one only needs one reference for the
> codepoint allocation.
>
> >>> It is not prohibited, for TLS 1.2 the extension is already specified:
> [ https://tools.ietf.org/html/draft-serhrouchni-tls-certieee1609-01 ]
> [ https://tools.ietf.org/html/draft-serhrouchni-tls-certieee1609-01 |
> https://tools.ietf.org/html/draft-serhrouchni-tls-certieee1609-01 ]
> We will update the draft
>
> - I found the document quite hard to read due to various editorial
> issues.
> >> We will update the draft
>
>
> Kind Regards
> Mounira
>
> - Mail original -
> De: "Ilari Liusvaara" 
> À: "Mounira Msahli" 
> Cc: "tls" 
> Envoyé: Vendredi 24 Août 2018 17:50:38
> Objet: Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE
> 1609.2 certificates
>
> On Fri, Aug 24, 2018 at 04:09:43PM +0200, Mounira Msahli wrote:
> > Hi all,
> >
> >
> > The draft: TLS 1.3 Authentication using IEEE 1609.2/ETSI TS 103097
> certificates is updated in accordance with TLS 1.3:
> https://tools.ietf.org/html/draft-tls-certieee1609-01
> >
> > This document describes the use of certificates specified by the
> Institute of Electrical and Electronics Engineers IEEE1609.2 and the
> European Telecommunications Standards
> >
> > Institute ETSI TS 103097. These standards are defined in order to secure
> communications in vehicular environments.
> >
> > This extension is very useful and has become a pressing need for
> (Vehicle-To-Internet(V2Internet), Vehicle-To-Cloud(V2Cloud),...).
> >
> > We are soliciting feedback from the WG on the draft.
>
> Some quick comments:
>
> - I did not see requirements where to place the end-entity certificate
> anywhere. I think most TLS code outright assumes that the end-entity
> certificate is the first one.
> - More generally, I did not see it specified how the certificate chain
> is laid out to the individual certficate fields (it is fairly
> obvious, but should still be specified).
> - The examples could have multiple certificate types in ClientHello to
> more clearly show what is actually going on.
> - You should also specify use in TLS 1.2 in the same draft (or say that
> is prohibited). This is so one only needs one reference for the
> codepoint allocation.
> - I found the document quite hard to read due to various editorial
> issues.
>
>
> -Ilari
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
> _

Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates

[William Whyte]

Hi all -- as editor of 1609.2 (and a contributor to 103 097) I'd like to
recommend that the WG moves forward with consideration of this draft. There
are a number of initiatives in the connected vehicle space that need TLS
with 1609.2 certificates, and in particular ISO 21177, which is currently
in ballot, assumes that TLS-with-1609.2 will be available shortly.

I have some comments on the detail of the draft which I'll share with the
editorial team, but regardless of how those comments are resolved I think
this is an important document and we should try to process it quickly.

Cheers,

William

On Fri, Aug 24, 2018 at 10:09 AM, Mounira Msahli <
mounira.msa...@telecom-paristech.fr> wrote:

> Hi all,
>
>
> The draft: TLS 1.3 Authentication using IEEE 1609.2/ETSI TS 103097
> certificates is updated in accordance with TLS 1.3:
> https://tools.ietf.org/html/draft-tls-certieee1609-01
>
> This document describes the use of certificates specified by the Institute
> of Electrical and Electronics Engineers IEEE1609.2 and the European
> Telecommunications Standards
>
> Institute ETSI TS 103097. These standards are defined in order to secure
> communications in vehicular environments.
>
> This extension is very useful and has become a pressing need for
> (Vehicle-To-Internet(V2Internet), Vehicle-To-Cloud(V2Cloud),...).
>
> We are soliciting feedback from the WG on the draft.
>
>
>
> Kind Regards
> Mounira
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>


-- 


PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS:
wwh...@onboardsecurity.com
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] AdditionalKeyShare Internet-Draft

[William Whyte]

Sorry! Link to the most recent version... https://tools.ietf.org/html/
draft-whyte-qsh-tls13-04

William

On Thu, Apr 20, 2017 at 1:08 PM, William Whyte 
wrote:

> Link to that draft: https://tools.ietf.org/html/draft-whyte-qsh-tls13-02
>
> Cheers,
>
> William
>
> On Wed, Apr 19, 2017 at 2:42 PM, Scott Fluhrer (sfluhrer) <
> sfluh...@cisco.com> wrote:
>
>>
>> > -Original Message-
>> > From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Douglas Stebila
>> > Sent: Monday, April 17, 2017 2:24 PM
>> > To: 
>> > Subject: [TLS] AdditionalKeyShare Internet-Draft
>> >
>> > Dear TLS mailing list,
>> >
>> > We have posted an Internet-Draft
>> > https://tools.ietf.org/html/draft-schanck-tls-additional-ke
>> yshare-00
>> > for using an additional key share in TLS 1.3.  The intended use case is
>> to
>> > provide support for transitional key exchange mechanisms in which both a
>> > pre-quantum algorithm (e.g., ECDH) and a post-quantum algorithm are
>> used.
>> > (Google's experiment with New Hope in 2016 had such an arrangement.) Our
>> > draft replicates the functionality of the KeyShare extension in a new
>> > extension called AdditionalKeyShare. Like KeyShare, the client's
>> > AdditionalKeyShare contains a vector of KeyShareEntry structs. The
>> server
>> > can respond with a single matching KeyShareEntry in the
>> AdditionalKeyShare
>> > extension of its ServerHello. The resulting additional shared secret is
>> included
>> > in the TLS key schedule after the ECDH shared secret.
>> >
>> > While the motivation for our Internet-Draft is to facilitate the
>> transition to
>> > post-quantum algorithms, our Internet-Draft does not specify any post-
>> > quantum algorithms.
>>
>> We have a draft with similar goals; draft-whyte-qsh-tls13 .  It also
>> tries to achieve Quantum-safeness through multiple key exchange mechanisms;
>> however in terms of protocol, it works somewhat differently.  You have the
>> 'normal' key exchange (as exists in the protocol), and a second one on the
>> side.  We allows the client to define a hybrid group (which consists of
>> several key exchanges done in parallel).  One of our goals was to stay
>> within the existing TLS architecture as much as possible (and thus limiting
>> the changes needed to the TLS state machine and parsing logic); things such
>> as modifying the key derivation mechanism (such as you do) were considered
>> to be too large.
>>
>> It may be worth your while to go through our draft,,,
>>
>> >
>> > There are a couple of items for discussion related to this draft:
>> >
>> > - We only provide a mechanism for a single AdditionalKeyShare, thus
>> leading
>> > to
>> >   the session establishing at most PSK + ECDHE + 1 additional shared
>> secret.  Is
>> >   there a value in even more shared secrets than that? Will someone want
>> >   to include more than one post-quantum algorithm?  If so, our draft
>> could be
>> >   adapted to have AdditionalKeyShare1, AdditionalKeyShare2, etc., but we
>> > did not
>> >   want to add that complexity unless there was desire for it.
>>
>> Our draft allows for that naturally.
>>
>> As for the need, well, I expect that some will want it.  We don't have
>> any postquantum key exchanges that are both practical and really well
>> trusted (at least, to the same extent that (EC)DH is); I would expect that
>> some people will want to spread their risk and do (for example) x25519 +
>> Frodo + SIDH.
>>
>> >
>> > - TLS 1.3 allows the client to restrict the use of PSKs that they
>> provide in
>> >   ClientHello through the "psk_key_exchange_modes" extension. The client
>> > may,
>> >   for instance, request that the PSK only be used in a PSK+(EC)DHE
>> mode, so
>> > as
>> >   to ensure that the resumed session has forward secrecy.  It is
>> unclear the
>> >   best way to reconcile this with support for multiple key shares; we
>> outline
>> >   some possibilities in Section 4 of our Internet-Draft, and we welcome
>> input.
>> >
>> > We have also created a pull request to TLS 1.3 draft 19 which includes a
>> > clarification on how additional secrets are to be included in the TLS
>> key
>> > schedule.
>> > https://github.com/jschanck/tls13-spec
>> >
>> > John and Douglas
>> >
>> > ___
>> > 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] AdditionalKeyShare Internet-Draft

[William Whyte]

Link to that draft: https://tools.ietf.org/html/draft-whyte-qsh-tls13-02

Cheers,

William

On Wed, Apr 19, 2017 at 2:42 PM, Scott Fluhrer (sfluhrer) <
sfluh...@cisco.com> wrote:

>
> > -Original Message-
> > From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Douglas Stebila
> > Sent: Monday, April 17, 2017 2:24 PM
> > To: 
> > Subject: [TLS] AdditionalKeyShare Internet-Draft
> >
> > Dear TLS mailing list,
> >
> > We have posted an Internet-Draft
> > https://tools.ietf.org/html/draft-schanck-tls-additional-keyshare-00
> > for using an additional key share in TLS 1.3.  The intended use case is
> to
> > provide support for transitional key exchange mechanisms in which both a
> > pre-quantum algorithm (e.g., ECDH) and a post-quantum algorithm are used.
> > (Google's experiment with New Hope in 2016 had such an arrangement.) Our
> > draft replicates the functionality of the KeyShare extension in a new
> > extension called AdditionalKeyShare. Like KeyShare, the client's
> > AdditionalKeyShare contains a vector of KeyShareEntry structs. The server
> > can respond with a single matching KeyShareEntry in the
> AdditionalKeyShare
> > extension of its ServerHello. The resulting additional shared secret is
> included
> > in the TLS key schedule after the ECDH shared secret.
> >
> > While the motivation for our Internet-Draft is to facilitate the
> transition to
> > post-quantum algorithms, our Internet-Draft does not specify any post-
> > quantum algorithms.
>
> We have a draft with similar goals; draft-whyte-qsh-tls13 .  It also tries
> to achieve Quantum-safeness through multiple key exchange mechanisms;
> however in terms of protocol, it works somewhat differently.  You have the
> 'normal' key exchange (as exists in the protocol), and a second one on the
> side.  We allows the client to define a hybrid group (which consists of
> several key exchanges done in parallel).  One of our goals was to stay
> within the existing TLS architecture as much as possible (and thus limiting
> the changes needed to the TLS state machine and parsing logic); things such
> as modifying the key derivation mechanism (such as you do) were considered
> to be too large.
>
> It may be worth your while to go through our draft,,,
>
> >
> > There are a couple of items for discussion related to this draft:
> >
> > - We only provide a mechanism for a single AdditionalKeyShare, thus
> leading
> > to
> >   the session establishing at most PSK + ECDHE + 1 additional shared
> secret.  Is
> >   there a value in even more shared secrets than that? Will someone want
> >   to include more than one post-quantum algorithm?  If so, our draft
> could be
> >   adapted to have AdditionalKeyShare1, AdditionalKeyShare2, etc., but we
> > did not
> >   want to add that complexity unless there was desire for it.
>
> Our draft allows for that naturally.
>
> As for the need, well, I expect that some will want it.  We don't have any
> postquantum key exchanges that are both practical and really well trusted
> (at least, to the same extent that (EC)DH is); I would expect that some
> people will want to spread their risk and do (for example) x25519 + Frodo +
> SIDH.
>
> >
> > - TLS 1.3 allows the client to restrict the use of PSKs that they
> provide in
> >   ClientHello through the "psk_key_exchange_modes" extension. The client
> > may,
> >   for instance, request that the PSK only be used in a PSK+(EC)DHE mode,
> so
> > as
> >   to ensure that the resumed session has forward secrecy.  It is unclear
> the
> >   best way to reconcile this with support for multiple key shares; we
> outline
> >   some possibilities in Section 4 of our Internet-Draft, and we welcome
> input.
> >
> > We have also created a pull request to TLS 1.3 draft 19 which includes a
> > clarification on how additional secrets are to be included in the TLS key
> > schedule.
> > https://github.com/jschanck/tls13-spec
> >
> > John and Douglas
> >
> > ___
> > 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] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead

[William Whyte]

There's an argument that it's worth building in a 256-bit cipher for
quantum resistance. Not clear that AES-256 is the best 256-bit cipher
though.

William

On Fri, Feb 24, 2017 at 9:07 AM, Salz, Rich  wrote:

> > Assuming 256-bit AES-CCM suites are needed, I think the better place to
> put
> > them is in the TLS 1.3 document.
>
> That's a really big assumption. ;)
>
> I think the burden is on folks to *prove* (yeah, I know) that additional
> cipher suites are needed.
> ___
> 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] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead

[William Whyte]

Right. I fee l strongly that it'd be wise to bless a single 256-bit cipher
as part of the core TLS 1.3 family of techniques, but I don't feel strongly
that it should be AES-256. ChaCha?

Cheers,

William

On Fri, Feb 24, 2017 at 9:55 AM, Salz, Rich  wrote:

> > There's an argument that it's worth building in a 256-bit cipher for
> quantum resistance. Not clear that AES-256 is the best 256-bit cipher
> though.
>
> Yes, I get that.
>
> "not clear" is a highly uncompelling argument, tho.
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-sullivan-tls-exported-authenticator-00

[William Whyte]

That makes sense, but it'd be good to clarify the text. Thanks!

William

-- sent from my phone

On Nov 1, 2016 11:57 AM, "Ilari Liusvaara"  wrote:

> On Tue, Nov 01, 2016 at 04:41:44AM -0400, William Whyte wrote:
> > I'm confused by the line "These messages are not encrypted", because on a
> > plain reading it could mean that the authenticator is sent outside the
> > encrypted TLS session. That would be bad because it would mean that
> clients
> > that wanted to authenticate themselves but to the server only wouldn't be
> > able to use this mechanism. I assume that's not the intent? If that isn't
> > the intent, suggest rephrasing as "These messages are not encrypted,
> other
> > than the encryption provided on transmission by the TLS session".
>
> What I think it means that the authenticator is not encrypted before
> handing it to the application for transport (most probably ultimately
> ending inside the TLS connection itself, which does encrypt it on the
> wire).
>
>
> Also, the message emitted is formatted as follows, right?
>
> - Byte 0x0B (CERTIFICATE code)
> - 3-byte length of Certificate message
> - Standard TLS 1.3 Certificate message payload
> - Byte 0x0F (CERTIFICATE_VERIFY code)
> - 3-byte length of CertificateVerify message
> - Standard TLS 1.3 CertificateVerify message payload
> - Byte 0x14 (FINISHED code)
> - 3-byte length of Finished message
> - Standard TLS 1.3 Finished message payload
>
>
>
>
> -Ilari
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-sullivan-tls-exported-authenticator-00

[William Whyte]

I'm confused by the line "These messages are not encrypted", because on a
plain reading it could mean that the authenticator is sent outside the
encrypted TLS session. That would be bad because it would mean that clients
that wanted to authenticate themselves but to the server only wouldn't be
able to use this mechanism. I assume that's not the intent? If that isn't
the intent, suggest rephrasing as "These messages are not encrypted, other
than the encryption provided on transmission by the TLS session".

Cheers,

William

On Mon, Oct 31, 2016 at 5:29 PM, Nick Sullivan 
wrote:

>  
> draft-sullivan-tls-exported-authenticator-00>
> 
>
> I just posted a new Internet-Draft called "Exported Authenticators in TLS"
> in the TLS working group.
>
> The intent of this draft is to enable participants in a TLS connection to
> prove ownership of additional certificates. This differs from previous
> proposals (https://tools.ietf.org/html/draft-sullivan-tls-post-
> handshake-auth-00) in that these proofs are not sent as part of the TLS
> connection, but instead exported so that they can be sent out of band (as
> part of an application layer message, for example).
>
> This proposal should enable a radical simplification of the Secondary
> Certificate Authentication in HTTP/2 proposal (
> https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-01),
> and should generally be a useful tool for binding a certificate ownership
> proof to a TLS connection.
>
> Nick Sullivan
>
> ___
> 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] PR #604 Change "supported_groups" to "supported_kems"

[William Whyte]

I'd like to just check and see if there are any objections to this PR.
There seems no reason to bake a particular cryptographic family into our
terminology. This is a low-cost change that will save us from looking silly
in a few years time.

Cheers,

William

On Tue, Sep 13, 2016 at 1:19 PM, Sean Turner  wrote:

> There appears to be no consensus to adopt the change proposed by this PR.
>
> The small condolence here is that the name+semantics for this extension
> has been changed once before and if the extension really needs to be
> renamed in 5-7 years we’ve got precedence for doing so.
>
> spt
>
> > On Aug 29, 2016, at 15:52, Zhenfei Zhang 
> wrote:
> >
> > Hi list,
> >
> >
> >
> > I have created a pull request
> >
> > https://github.com/tlswg/tls13-spec/pull/604
> >
> >
> >
> > I would like to suggest that we change the terminology "NamedGroup" to
> "KeyExchangeMethod".
> >
> >
> >
> > In [1], it is suggested that we redefine the syntax, which leads to the
> separation of public key crypto
> >
> > and symmetric crypto during a handshake. Because of this separation, new
> terminology was defined
> >
> > for key exchange algorithms and authentication algorithms for public key
> crypto in the key exchange
> >
> > extension. "NamedGroup" was used to refer the underlying key exchange
> parameters, which comes
> >
> > from the "Supported Elliptic Curves" in previous versions.
> >
> >
> >
> > The use of "NamedGroup" implicitly requests the key exchange algorithm
> to be Deffie-Hellman type.
> >
> > While it is safe for now, it would be nice to have some crypto agility,
> and future proof. It would make
> >
> > the transition to other key exchange primitives (such as lattice based
> key exchange) or methods
> >
> > (such as key encapsulation mechanism) easier in the future, if we do not
> restrict the key exchange
> >
> > by certain "Group".
> >
> >
> >
> > Knowing that NIST has planned to standardize quantum-safe cryptography
> within 7 years of time
> >
> > (which can and should be accelerated), and those algorithms cannot be
> described in terms of "group",
> >
> > the current terminology will due for a redesign by then. So I would
> suggest to change the
> >
> > "NamedGroup" now rather than later.
> >
> >
> >
> >
> > Overall, this will have the following impact
> >
> >
> >
> > 1. HelloRetryRequest
> >
> >
> >
> > Change HelloRetryRequest structure to
> >
> >
> >
> > struct {
> >
> > ProtocolVersion server_version;
> >
> > KeyExchangeMethod selected_kem;
> >
> > Extension extensions<0..2^16-1>;
> >
> > } HelloRetryRequest;
> >
> >
> >
> > 2. Negotiated Groups
> >
> >
> >
> > Throughout, change "supported_groups" to "supported_kems"; change
> "NamedGroupList" to
> > "KeyExchangeMethodList"; change "named_group_list" to "kem_list"; change
> NamedGroup to
> >
> > KeyExchangeMethod
> >
> >
> >
> > 3. Key Share:
> >
> > Change KeyShareEntry structure to
> >
> >
> >
> > struct {
> >
> > KeyExchangeMethod kem;
> >
> > opaque key_exchange<1..2^16-1>;
> >
> > } KeyShareEntry;
> >
> >
> > [1] https://github.com/ekr/tls13-spec/blob/
> 15126cf5a08c445aeed97c0c25c4f10c2c1b8f26/draft-ietf-tls-tls13.md
> >
> >
> >
> > Thanks for your time.
> >
> >
> >
> > Zhenfei Zhang
> >
> > ___
> > 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] bikeshed: Forward Security or Secrecy?

[William Whyte]

If we want to change to “key erasure” we should synch with CFRG and SAAG to
ensure it’s used IETF-wide. I don’t think that “forward secrecy” is so
broken that it needs fixing.



Cheers,



William



*From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Tony Arcieri
*Sent:* Monday, November 30, 2015 11:20 PM
*To:* Hugo Krawczyk
*Cc:* tls@ietf.org
*Subject:* Re: [TLS] bikeshed: Forward Security or Secrecy?



On Mon, Nov 30, 2015 at 8:09 PM, Hugo Krawczyk 
wrote:

The more common term is "forward secrecy"



I'd second this. I'm also a fan of Dan Bernstein's recommended term: "key
erasure"



-- 

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

[TLS] Fwd: New Version Notification for draft-whyte-qsh-tls13-01.txt

[William Whyte]

Hi all,

We've updated the TLS 1.3 Quantum Safe Handshake draft to use extensions as
suggested by DKG in Prague. All comments welcome.

There's an interesting issue here: McEliece keys, which should be
permissible, are larger in size (about 2^20 bytes) than the maximum
permissible extension size (2^16-1). In order to support McEliece keys it
might be worth increasing the maximum extension size to 2^24-1 for TLS 1.3.
Is there a strong reason for keeping the maximum size at 2^24-1, other than
saving one byte on all the relevant length fields?

Cheers,

William




-- Forwarded message --
From: 
Date: Sun, Sep 20, 2015 at 10:32 PM
Subject: New Version Notification for draft-whyte-qsh-tls13-01.txt
To: Zhenfei Zhang , William Whyte <
wwh...@securityinnovation.com>, "John M. Schanck" <
jscha...@securityinnovation.com>



A new version of I-D, draft-whyte-qsh-tls13-01.txt
has been successfully submitted by William Whyte and posted to the
IETF repository.

Name:   draft-whyte-qsh-tls13
Revision:   01
Title:  Quantum-Safe Hybrid (QSH) Ciphersuite for Transport Layer
Security (TLS) version 1.3
Document date:  2015-09-20
Group:  Individual Submission
Pages:  18
URL:
https://www.ietf.org/internet-drafts/draft-whyte-qsh-tls13-01.txt
Status: https://datatracker.ietf.org/doc/draft-whyte-qsh-tls13/
Htmlized:   https://tools.ietf.org/html/draft-whyte-qsh-tls13-01
Diff:   https://www.ietf.org/rfcdiff?url2=draft-whyte-qsh-tls13-01

Abstract:
   This document describes the Quantum-Safe Hybrid ciphersuite, a new
   cipher suite providing modular design for quantum-safe cryptography
   to be adopted in the handshake for the Transport Layer Security (TLS)
   protocol version 1.3.  In particular, it specifies the use of the
   NTRUEncrypt encryption scheme in a TLS handshake.





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

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