[TLS] Weekly github digest (TLS Working Group Drafts)

[Repository Activity Summary Bot]

Issues
--
* tlswg/tls-flags (+0/-1/0)
 1 issues closed:
 - 63 or 247? https://github.com/tlswg/tls-flags/issues/1 




Pull requests
-
* tlswg/dtls-conn-id (+0/-0/1)
 1 pull requests received 1 new comments:
 - #71 Corrected reference to the RRC draft (1 by boaks)
   https://github.com/tlswg/dtls-conn-id/pull/71 


* tlswg/tls-subcerts (+1/-0/0)
 1 pull requests submitted:
 - Revise an introductory paragraph for greater clarity. (by cbartle891)
   https://github.com/tlswg/tls-subcerts/pull/51 



Repositories tracked by this digest:
---
* https://github.com/tlswg/draft-ietf-tls-semistatic-dh
* https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate
* https://github.com/tlswg/draft-ietf-tls-esni
* https://github.com/tlswg/certificate-compression
* https://github.com/tlswg/draft-ietf-tls-external-psk-importer
* https://github.com/tlswg/draft-ietf-tls-ticketrequest
* https://github.com/tlswg/tls-flags
* https://github.com/tlswg/dtls13-spec
* https://github.com/tlswg/dtls-conn-id
* https://github.com/tlswg/tls-subcerts
* https://github.com/tlswg/oldversions-deprecate
* https://github.com/tlswg/sniencryption
* https://github.com/tlswg/tls-exported-authenticator
* https://github.com/tlswg/draft-ietf-tls-grease
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-external-psk-importer-03.txt

[Christopher Wood]

This update fixes some formatting issues and removes a lingering TODO (pointing 
to analysis, which shouldn't block things). 

Best,
Chris (no hat)

On Sat, Feb 15, 2020, at 4:54 PM, internet-dra...@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Transport Layer Security WG of the IETF.
> 
> Title   : Importing External PSKs for TLS
> Authors : David Benjamin
>   Christopher A. Wood
>   Filename: draft-ietf-tls-external-psk-importer-03.txt
>   Pages   : 11
>   Date: 2020-02-15
> 
> Abstract:
>This document describes an interface for importing external PSK (Pre-
>Shared Key) into TLS 1.3.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-importer/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-03
> https://datatracker.ietf.org/doc/html/draft-ietf-tls-external-psk-importer-03
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-external-psk-importer-03
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

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

[TLS] I-D Action: draft-ietf-tls-external-psk-importer-03.txt

[internet-drafts]

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

Title   : Importing External PSKs for TLS
Authors : David Benjamin
  Christopher A. Wood
Filename: draft-ietf-tls-external-psk-importer-03.txt
Pages   : 11
Date: 2020-02-15

Abstract:
   This document describes an interface for importing external PSK (Pre-
   Shared Key) into TLS 1.3.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-03
https://datatracker.ietf.org/doc/html/draft-ietf-tls-external-psk-importer-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-external-psk-importer-03


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

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

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

Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design

[Loganaden Velvindron]

I support adoption and I'm willing to review the document.

On Wednesday, February 12, 2020, Douglas Stebila  wrote:

> Dear TLS working group,
>
> We would like to request the working group adopt
> draft-stebila-tls-hybrid-design, "Hybrid key exchange in TLS 1.3", as
> a working group item.  We have updated the draft based on feedback
> we've received over the past few months, including from our
> presentations at IETF 104 and 105, and think the current version
> represents the view of the WG to date.
>
> https://datatracker.ietf.org/doc/draft-stebila-tls-hybrid-design/
>
> Cheers,
>
> 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

Re: [TLS] Requesting working group adoption of draft-stebila-tls-hybrid-design

[Ilari Liusvaara]

On Wed, Feb 12, 2020 at 02:26:21PM -0500, Douglas Stebila wrote:
> Dear TLS working group,
> 
> We would like to request the working group adopt
> draft-stebila-tls-hybrid-design, "Hybrid key exchange in TLS 1.3", as
> a working group item.  We have updated the draft based on feedback
> we've received over the past few months, including from our
> presentations at IETF 104 and 105, and think the current version
> represents the view of the WG to date.
> 
> https://datatracker.ietf.org/doc/draft-stebila-tls-hybrid-design/

Some comments and related sidenotes:

- If additional round trips are to be avoided, the public key size
  should be kept low so client hello does not grow so large that
  significant amount of servers barf on it. [LANGLEY] notes that
  3300 bytes was about the maximum they could use.

- That TLS 1.3 does not talk about client-side key reuse seems to
  be a mistake. It for example says SHOULD NOT reuse tickets, with
  rationale that also appiles to client side keys.

- The draft talks about "any KEM used in this document". Which sounds
  odd, given that this document does not define any KEMs.

- The reasons to not reuse public keys, even with CCA-secure KEMs,
  impiles that the relevant benchmarks are:

  * Combined key generation and decapsulation time.
  * Single-thread encapsulation time.
  * Peak memory usage by key generation and decapsulation.
  * Peak memory usage by encapsulation.
  * Size of public key
  * Size of ciphertext
 
  For KEMs used as key exchanges, using decapsulation time alone is
  perverse due to problems with key reuse, again even with CCA-secure
  KEMs.

- Assigning specific range for Hybrid KEX. What is the use of that?
  The server recognizing that client supports Hybrid KEX even if there
  is no algorithm overlap? What the server would do with that
  information?

- The draft has specific data structures. This only makes sense if
  other drafts are to refer to it or are intended to copy the data
  structure definitions. It also has processing algorithms, which only
  makes sense to me if other drafts are to refer to this one.

  Being informational, referencing could lead to downref, but this
  should not be a significant problem.

- I do not view supporting large public keys or ciphertexts as
  realistic.

  Making larger extension would mean extending TLS to support
  "extended extensions". This would impily extra RTT for most key
  exchanges, altough it could be absorbed into extra RTT for client
  missing speculation on group (so it would be 2-RTT).

  Referencing external key is not acceptable:

  * The client would need to have a way to publish its key.
  * Strong incentives to reuse keys, despite problems doing so.
  * The server would need to be able to fetch keys, which causes
difficult security issues.
  * The server would need to freeze the handshake for obtaining
the public key. Unless the server API already supports handshake
freezing, adding that capability is going to be virtually
impossible (let alone the annoyance of implementing it).

  Additionally, even if blowing the practical ClientHello size limit
  (4kB or so) would already force additional round trip, the >64kB
  key algorithms have such big keys that result would be severe
  performance degradation.

  So in summary, unless all the smaller algorithms are broken beyond
  repair (which is highly unlikely due to complexity reasons) the
  >64kB keys should not be accomodiated. And even in that case, external
  keys are not acceptable.

- Avoiding duplication of key shares is difficult problem:

  * Using traditional scheme is easy on client and server, but can
result in duplication of shares. And even single duplication of
PQ share is signficant.
  * Making ServerHello key_share a list is clean specification-wise,
but might be anything but clean implementation-wise.
  * Making separate extension could cause issues when doing
hybrid -> next-gen transition in future.
  * Backreferences could be annoying to implement.

- On resumption, I do not think there are currently any restrictions
  in TLS 1.3 about DH groups used in resumption?

  If that is indeed the case, I suspect that implementing such
  restrictions might turn to be annoying to implement.

- On failures: All CCA-secure key exchanges have negligible failure
  rates (because anything else leads to attacks). And even if one
  considers non-CCA key exchanges from the NISTPQC 2nd round, AFAIK
  all of them meant for actual use have failure rate <10^-9.

- On schemes vulernable to chosen-ciphertext attack, SIDH (which
  underlies SIKE) key can be recovered bit-by-bit (even with just
  guess oracle, instead of full decryption oracle) by sending suitable
  chosen ciphertexts. This takes a few hundred samples for full key
  recovery.


-Ilari

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

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

[Ilari Liusvaara]

On Fri, Feb 14, 2020 at 11:27:36AM -0800, Nick Sullivan wrote:
> Ilari,
> 
> Thank you for identifying these errors in the document. There was no
> intention to allow the client to constrict the server certificate's
> algorithm with the delegated_credential extension, and no intention to
> restrict the delegated credential's algorithm with the
> signature_algorithms. Let me propose some minor text changes to address the
> issues.
> 
> As a reminder, the CertificateVerify.algorithm is constrained by the
> signature_algorithms
> extension, as stated in RFC 8446:
> 
>If the CertificateVerify message is sent by a server, the signature
>algorithm MUST be one offered in the client's "signature_algorithms"
>extension unless no valid certificate chain can be produced without
>unsupported algorithms (see Section 4.2.3
> ).
> 
> 
> 
> Original text from 4.1.2.:
> 
>The expected_cert_verify_algorithm fields MUST be of a
>type advertised by the client in the SignatureSchemeList and are
>considered invalid otherwise.  Clients that receive invalid delegated
>credentials MUST terminate the connection with an "illegal_parameter"
>alert.
> 
> 
> proposed text:
> 
>The expected_cert_verify_algorithm field MUST be of a
>type advertised by the client in the SignatureSchemeList and is
>considered invalid otherwise.  Clients that receive invalid delegated
>credentials MUST terminate the connection with an "illegal_parameter"
>alert.

The section number looks incorrect (it is about client authentication)
and the original looks to be copied from the new text. Did you mean
section 4.1.1 (Server authentication) and:

OLD:

   The algorithm and expected_cert_verify_algorithm fields MUST be of a
   type advertised by the client in the SignatureSchemeList and are
   considered invalid otherwise.  Clients that receive invalid delegated
   credentials MUST terminate the connection with an "illegal_parameter"
   alert.

NEW:

   The expected_cert_verify_algorithm field MUST be of a
   type advertised by the client in the SignatureSchemeList and is
   considered invalid otherwise.  Clients that receive invalid delegated
   credentials MUST terminate the connection with an "illegal_parameter"
   alert.


> As for the second point, we did not add the capability for the server to
> advertise a different set of signature_algorithms for client authentication
> other than the one advertised via the "signature_algorithms" extension.
> This was perhaps an oversight. I propose that we add that capability and
> I'd be happy to propose a PR to that effect.
> 
> The new text of 4.3.2. would look something like:
> 
>A server which supports this specification SHALL send an
>"delegated_credential" extension in the CertificateRequest message
>when requesting client authentication.  The body of the
>extension consists of a SignatureSchemeList.  If the server receives a
>delegated credential without indicating support in its
>CertificateRequest, then the server MUST abort with an
>"unexpected_message" alert.
> 
> ...
> 
>The algorithm field MUST be of a
>type advertised by the server in the "signature_algorithms" extension
>of the CertificateRequest message and the expected_cert_verify_algorithm
>field MUST be of a type advertised by the client in the SignatureSchemeList
>and considered invalid otherwise.  Clients that receive invalid
>delegated credentials MUST terminate the connection with an
>"illegal_parameter" alert.
> 

There seems to be no section 4.3.2 (or 4.3 for that matter). Did you mean
section 4.1.2 (Client authentication)?  The latter proposed paragraph
seems like it says "client" in two places it should say  "server", did you
mean:

   The algorithm field MUST be of a
   type advertised by the server in the "signature_algorithms" extension
   of the CertificateRequest message and the expected_cert_verify_algorithm
   field MUST be of a type advertised by the server in the SignatureSchemeList
   and considered invalid otherwise.  Servers that receive invalid
   delegated credentials MUST terminate the connection with an
   "illegal_parameter" alert.



-Ilari

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