Re: [TLS] Un-deprecating everything TLS 1.2

[Christopher Patton]

A couple pointers for getting started:

   1. Check out Dowling et al.'s recent analysis. Published a month or so
   ago, it's the most recent proof of security of the full handshake (also
   includes PSK modes): https://eprint.iacr.org/2020/1044
   2. Check out Paterson and van der Merwe's survey of the body of papers
   that helped to shape TLS 1.3. It also overviews the myriad attacks against
   TLS 1.2 and below that catalyzed a more proactive design approach for 1.3:
   https://link.springer.com/chapter/10.1007/978-3-319-49100-4_7

If you're unable to download the second (2.), the same paper appears in a
slightly different form in van der Merwe's PhD thesis.

No analysis is perfect, but so far, 1.3 appears to be far superior to
1.0-1.2.

Best,
Chris P.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] AD review of draft-ietf-tls-md5-sha1-deprecate-03

[Sean Turner]

Roman,

Thanks for your review. Some comments inline.

spt

> On Oct 2, 2020, at 19:42, Roman Danyliw  wrote:
> 
> Hi!
> 
> I've assumed the role of responsible AD on this document.  As such, I 
> performed an AD review of draft-ietf-tls-md5-sha1-deprecate-03.  
> 
> Thanks for writing this document to address an important crypto maintenance 
> tasks in TLS v1.2.  I have a few clarifying and pro forma editorial items of 
> feedback.  
> 
> ** Please address the following IDNits:
> 
> -- The document seems to lack an IANA Considerations section.  (See Section
> 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
> when there are no actions for IANA.)

Addressed via:
https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/pull/7

Comments about one below, but the remaining are addressed via:
https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/pull/8

> -- The draft header indicates that this document updates RFC5246, but the
> abstract doesn't seem to mention this, which it should.
> 
> -- The draft header indicates that this document updates RFC7525, but the
> abstract doesn't seem to mention this, which it should.
> 
> ** Section 1.  Editorial. 
> -- s/RFC 5246 [RFC5246]/[RFC5246]/
> 
> -- s/RFC 6151 [RFC6151]/[RFC6151]/
> 
> -- s/RFC7525 [RFC7525]/[RFC7525]/
> 
> ** Section 1.  Editorial.  For symmetry with the rest of the text:
> 
> OLD
> RFC 6151 [RFC6151]
>   details the security considerations, including collision attacks for
>   MD5, published in 2011.  
> 
> NEW
> In 2011, [RFC6151]  detailed the security considerations, including collision 
> attacks for MD5.  
> 
> ** Section 1.  Please provide a reference for "Wang, et al".  Is there a 
> reference to provide for the "the potential for brute-force attack"

For the Wang attack we used the following reference when updating the SHA-0 and 
SHA-1 considerations. I put it where the collisions are first noted. I am 
unsure if it’s the latest and greatest:

Wang, X., Yin, Y., and H. Yu., "Finding Collisions in
 the Full SHA-1", Crypto 2005.



I am not sure there is a reference for the brute force potential attack, but 
somebody correct me if I am wrong. The way I see it if you know the collision 
space is much smaller well you might launch said attack.

In s1.1, I also updated the paragraph to use the new paragraph and fixed the 
references.

> ** Section 6.  Editorial Nit. s/RFC5246 [RFC5246]/[RFC5246]/
> 
> ** Section 6.  Move the text "In Section 7.4.1.4.1: the text should be 
> revised from" out of the "OLD" block of text to be its own intro paragraph so 
> that the OLD vs. NEW is  a clear cut-and-paste.
> 
> ** Section 7.  Editorial. s/ RFC7525 [RFC7525]/[RFC7525]/
> 
> ** Section 7.  SHA-1 is also not mentioned in RFC7525.  Recommend:
> 
> OLD
> The prior text did not explicitly include
>   MD5 and this text adds it to ensure it is understood as having been
>   deprecated.
> 
> NEW
> The prior text did not explicitly include MD5 or SHA-1; and this text adds 
> guidance to ensure that these algorithms have been deprecated.
> 
> ** Section 7.  Editorial.  Grammar.
> 
> OLD
> In addition, the use of the SHA-256 hash algorithm is RECOMMENDED,
>   SHA-1 or MD5 MUST NOT be used
> 
> NEW
> In addition, the use of the SHA-256 hash algorithm is RECOMMENDED; and SHA-1 
> or MD5 MUST NOT be used
> 
> ** Section 10.2  Please make RFC5246 a normative reference.
> 
> Regards,
> Roman
> 
> ___
> 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] AD review of draft-ietf-tls-external-psk-importer-05

[Sean Turner]

I submitted these as an Issue in the repo:
https://github.com/tlswg/draft-ietf-tls-external-psk-importer/issues/37

spt

> On Oct 1, 2020, at 16:22, Roman Danyliw  wrote:
> 
> ** Section 1.  Editorial.  Expand acronym on first use:
> -- s/TLS 1.2 PRF/TLS 1.2 Pseudorandom Function (PRF)/
> -- s/KDF/Key Derivation Function (KDF)/
> 
> ** Section 1. Editorial.  Since the text says "... this document specifies a 
> PSK Importer interface ... for use in D(TLS 1.3)" perhaps the this scoping 
> should also be upfront in the first sentence too:
> s/TLS 1.3 [RFC8446] supports/(D)TLS 1.3 [RFC8446][ID-DTLS]/
> 
> ** Section 4.1.  Editorial.  Per "The list of 'target_kdf' ...", other parts 
> of this text refer to elements of struct ImportIdentity with the notation 
> "ImportedIdentity.*".  Consider s/The list of "target_kdf" values/The list of 
> ImportedIdentity.target_kdf values/
> 
> ** Section 4.1.
> If the EPSK is a key derived from some other protocol or
>   sequence of protocols, ImportedIdentity.context MUST include a
>   channel binding for the deriving protocols [RFC5056].
> 
> To the end of this normative guidance, I'd recommend adding something to the 
> effect of: "The details of this binding will be protocol specific and out of 
> scope in this document".
> 
> ** Section 4.1.  Per "If no hash function is specified, SHA-256 MUST be used"
> 
> -- Please provide a reference for SHA-256 (per "... If no hash function is 
> specified, SHA-256 MUST be used").  
> 
> -- It is likely worth saying that this is the equivalent of HKDF_SHA256 
> (i.e., 0x0001)
> 
> ** Section 4.1.  Per "EPSKs may be imported before the started of the 
> connection ..." and "EPSKs may also be imported for early data use ..." 
> should be these be a normative MAYs?
> 
> ** Section 4.1.  Per "Minimally, that means ALPN, QUIC ... must be 
> provisioned alongside these EPSK"
> -- Please expand ALPN
> 
> -- should this be a normative MUST?
> 
> ** Section 9.  Per the columns in the registry:
> -- Is there a reason why there isn't a Reference column in the registry to 
> capture which specification describes the particular KDF?  I think it needs 
> one to eliminate guesswork from the label in "KDF Description" to an 
> algorithm.  
> 
> -- Was a Recommended column (and the associated processed for populating it 
> like a few of the other TLS registries) discussed/considered?
> 
> ** Section 9.  While it is implied by the label, the text doesn't explicitly 
> say what HKDF_SHA256 and _SHA384 are (per previous comment about needing a 
> reference).

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

Re: [TLS] AD review of draft-ietf-tls-exported-authenticator-13

[Sean Turner]

I have entered these as an issue in the repo:
https://github.com/tlswg/tls-exported-authenticator/issues/66

spt

> On Oct 2, 2020, at 12:50, Roman Danyliw  wrote:
> 
> Hi!
> 
> I've assumed the role of responsible AD on this document.  As such, I 
> performed an AD review of draft-ietf-tls-exported-authenticator-13.  This 
> document has seen a few WG LCs and reviews.  Thanks for working out the 
> details for this feedback.I have a few questions and suggestions for 
> process and editorial clarity described below.  Given that, I'm going to 
> advance this document to IETF LC and the feedback below can be 
> discussed/addressed concurrently.
> 
> ** Section 1.  Editorial. Provide a reference to TLS 1.3 when it is first 
> mentioned.
> 
> OLD
> Post-handshake authentication is defined in TLS 1.3
> 
> NEW
> Post-handshake authentication is defined in Section 4.6.2 of TLS 1.3 [TLS13]
> 
> ** Section 1.  Editorial. Provide references to for (D)TLS 1.2
> 
> OLD
> TLS (or DTLS) version 1.2 or later are REQUIRED
> 
> NEW
> TLS (or DTLS) version 1.2 [RFC5246][RFC6347] or later are REQUIRED.
> 
> ** Section 5.  
>   The
>   application layer protocol used to send the authenticator SHOULD use
>   TLS or a protocol with comparable security properties as its
>   underlying transport
> 
> I saw the additional text added here after the LC on -09 (and the discussion 
> that this can't be MUST-use-TLS because of use cases like QUIC).  However, 
> what is the envisioned flexibility by using SHOULD (instead of MUST) given 
> the addition of the "or a protocol with comparable security properties"?  
> When would I want to use a protocol with reduced security properties?
> 
> ** Section 5.1.  Editorial.
> 
> These values are derived
>   using an exporter as described in [RFC5705] (for TLS 1.2) or Sec. 7.5
>   of [TLS13] (for TLS 1.3).
> 
> -- Please provide the relevant section in RFC5705 (just like was done for 
> [TLS13])
> 
> -- s/Sec. 7.5/Section 7.5/
> 
> ** Section 5.2.2.  Editorial. Per "The definition for TLS 1.3 is:" begs the 
> question of what that format might be for TLS 1.2.  Can you please make it 
> clearer that the format is the same.
> 
> ** Section 5.2.2.  
> 
> Otherwise, the signature algorithm used
>   should be chosen from the "signature_algorithms" sent by the peer in
>   the ClientHello of the TLS handshake.  
> 
> -- Editorial.  For clarity, s/ Otherwise, the signature algorithm used 
> .../Otherwise, with spontaneous server authentication, the signature 
> algorithm used .../
> 
> -- Would it make sense to make this "should" and normative "SHOULD"?
> 
> ** Section 5.2.4.
>   When validating an
>   authenticator, a constant-time comparison SHOULD be used.
> 
> What's the concern here?  IMO, this guidance seems better in Section 7.4
> 
> ** Section 7.*.  As Section 7 states that 7.* is informative:
> -- Section 7.3. Downgrade the single normative "RECOMMENDED" to be 
> "recommended".
> 
> -- Section 7.4. Downgrade the single normative "SHOULD" to be "should"
> 
> ** Section 8.1.  Why shouldn't this document also be added to the "Reference" 
> column to explain the addition of "CR" to the "TLS 1.3" column?
> 
> ** Section 8.2.  With these additions to "Exporter Labels" registry, please 
> describe the values of the other fields:
> -- How should the "DTLS-OK" and "Recommended" columns be set?
> 
> -- The obvious text that this document should be the "Reference"
> 
> Regards,
> Roman
> 
> ___
> 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] Un-deprecating everything TLS 1.2

[Michael D'Errico]

On 10/5/20 10:21, Christopher Patton wrote:

A couple pointers for getting started:


Thank you for providing these links!  I'm going through
the first one now and will note that it does not even
mention the HelloRetryRequest message.  So while I am
confident there has been quite a bit of study of a
ClientHello -> ServerHello handshake, there may not
have been much study of ClientHello1 -> HelloRetryRequest
-> ClientHello2 -> ServerHello handshakes.

I'm especially concerned about the fact that a "stateless"
server does not even remember what the ClientHello1 or
HelloRetryRequest messages were when it receives the
second ClientHello.  Load-balanced data centers seem to
do this based on some of the discussion I've had this
week.

The protocol handles the missing ClientHello1 message by
replacing it with hash-of-ClientHello1, but then you're
supposed to rely on the client to tell you this value in
its ClientHello2.  Even if nothing funny is happening,
how is the (stateless) server supposed to put the
HelloRetryRequest message in the Transcript-Hash?  Where
does it get this value from if it's not also somehow in
the "cookie" (which is how the client reminds the server
of hash-of-ClientHello1)?

And how would you put the HelloRetryRequest message into
the cookie extension when the cookie itself is a part of
the HelloRetryRequest?

Just trying to imagine the code I'd have to write to do
this correctly makes my head spin:

  0)  [disable "TCP Fast Open" so I don't do lots of
  processing without knowing there's a routable
  address associated with the client]

  1)  receive ClientHello1

  2)  generate HelloRetryRequest message without cookie

  3)  package ClientHello1 and HelloRetryRequest-minus-
      cookie into a data structure, encrypt + MAC to
      create a cookie

  4)  insert the cookie into the HelloRetryRequest,
  remembering to update the length of the extensions

  5)  send HelloRetryRequest (with cookie) to client

  6)  erase all memory of what just happened!!!

  7)  receive ClientHello2

  8)  ensure it has a cookie extension (well I should
  at least remember the fact that I already sent a
      HelloRetryRequest and not be completely stateless,
  right?  Otherwise the client may be able to send
      many ClientHelloN's without a cookie)

  9)  check MAC on the cookie and if it's valid, decrypt
  it to determine the contents of ClientHello1 and
  the HelloRetryRequest (without cookie) messages

  10) MAKE SURE ClientHello2 is valid according to what
  was received in ClientHello1 (RFC 8446 has a list
  of things a client is allowed to do; I would want
  to check all of them, so a hash of ClientHello1
  is inadequate in my opinion).  This seems to be a
  necessary thing to do even for stateful servers.

  11) Recreate the actual HelloRetryRequest message
  that was sent to the client by putting the cookie
  into HRR-minus-cookie (in the same place within
  the list of extensions as was already done in step
  4, but since we threw it away, do it again)

  12) Hash the ClientHello1 and add this hash to the
  Transcript-Hash along with the HelloRetryRequest
      message

And I didn't even handle the possibility of replay.

Can a cryptographer (I don't claim to be one) please take a
few moments to look at the possibilities for a server which
doesn't implement step 8 and allows multiple ClientHello's
without a cookie on the same connection?  Or a server that
doesn't put the entire ClientHello1 into the cookie and can
not check whether ClientHello2 is conformant to the list of
allowed changes?  Or a server that has to maybe "guess" the
content of HelloRetryRequest based on ClientHello2 since it
just sent hash-of-ClientHello1 in the cookie?  And if it
guesses wrong and the Transcript-Hash ends up different
from the client, the peers will not be able to communicate
(denial of service to legitimate clients).

Implementers -- how do you put a HelloRetryRequest message
into the Transcript-Hash if you are "stateless" and threw
it in the bin along with ClientHello1?

Mike



 1. Check out Dowling et al.'s recent analysis. Published a month or
so ago, it's the most recent proof of security of the full
handshake (also includes PSK modes): https://eprint.iacr.org/2020/1044
 2. Check out Paterson and van der Merwe's survey of the body of
papers that helped to shape TLS 1.3. It also overviews the myriad
attacks against TLS 1.2 and below that catalyzed a more proactive
design approach for 1.3:
https://link.springer.com/chapter/10.1007/978-3-319-49100-4_7

If you're unable to download the second (2.), the same paper appears 
in a slightly different form in van der Merwe's PhD thesis.


No analysis is perfect, but so far, 1.3 appears to be far superior to 
1.0-1.2.


Best,
Chris P.


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

[TLS] I-D Action: draft-ietf-tls-rfc8446bis-00.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   : The Transport Layer Security (TLS) Protocol Version 
1.3
Author  : Eric Rescorla
Filename: draft-ietf-tls-rfc8446bis-00.txt
Pages   : 152
Date: 2020-10-05

Abstract:
   This document specifies version 1.3 of the Transport Layer Security
   (TLS) protocol.  TLS allows client/server applications to communicate
   over the Internet in a way that is designed to prevent eavesdropping,
   tampering, and message forgery.

   This document updates RFCs 5705 and 6066 and obsoletes RFCs 5077,
   5246, and 6961.  This document also specifies new requirements for
   TLS 1.2 implementations.


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

There is also an HTML version available at:
https://www.ietf.org/id/draft-ietf-tls-rfc8446bis-00.html


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] PR#28: Converting cTLS to QUIC-style varints

[Eric Rescorla]

Hi folks,

cTLS uses a bespoke varint format. Now that QUIC is nearly done, I propose
adopting their varint format.

https://github.com/tlswg/draft-ietf-tls-ctls/pull/28

Any objections?
-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR#28: Converting cTLS to QUIC-style varints

[Marten Seemann]

One thing that’s a bit annoying about QUIC’s variant format is that there
are multiple ways to encode a number. This has led to some complications in
the specification (e.g. QUIC requires you to use the minimal encoding for
frame types, but allows all encodings everywhere else).
It would be nice to have an unambiguous way to encode a number.

On Tue, Oct 6, 2020 at 07:35 Eric Rescorla  wrote:

> Hi folks,
>
> cTLS uses a bespoke varint format. Now that QUIC is nearly done, I propose
> adopting their varint format.
>
> https://github.com/tlswg/draft-ietf-tls-ctls/pull/28
>
> Any objections?
> -Ekr
>
> ___
> 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#28: Converting cTLS to QUIC-style varints

[Martin Thomson]

Oh, I consider that to be a feature.  One that I exploit.  It's sometimes 
awkward to build a structure then prepend a length that has a variable-length 
encoding.  If you know the maximum length, the varint encoding allows you to 
avoid having to move memory.

That said, cTLS won't authenticate both the value and the specific encoding of 
numeric values as the varint encoding is erased.  I don't consider that to be a 
serious problem, but it means that cTLS transcripts can't be directly compared. 
 I would note that in the draft: people shouldn't be processing cTLS messages 
that way, but they might be surprised to learn of this.

On Tue, Oct 6, 2020, at 12:31, Marten Seemann wrote:
> One thing that’s a bit annoying about QUIC’s variant format is that 
> there are multiple ways to encode a number. This has led to some 
> complications in the specification (e.g. QUIC requires you to use the 
> minimal encoding for frame types, but allows all encodings everywhere 
> else).
> It would be nice to have an unambiguous way to encode a number.
> 
> On Tue, Oct 6, 2020 at 07:35 Eric Rescorla  wrote:
> > Hi folks,
> > 
> > cTLS uses a bespoke varint format. Now that QUIC is nearly done, I propose 
> > adopting their varint format.
> > 
> > https://github.com/tlswg/draft-ietf-tls-ctls/pull/28
> > 
> > Any objections?
> > -Ekr
> > 
> > ___
> > 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] PR#28: Converting cTLS to QUIC-style varints

[Eric Rescorla]

Yeah, I'm certainly sympathetic to this. TBH, from an aesthetic perspective
I prefer what's in cTLS now (though it had the same property) but I figured
that some consistency was nice.

-Ekr



On Mon, Oct 5, 2020 at 6:31 PM Marten Seemann 
wrote:

> One thing that’s a bit annoying about QUIC’s variant format is that there
> are multiple ways to encode a number. This has led to some complications in
> the specification (e.g. QUIC requires you to use the minimal encoding for
> frame types, but allows all encodings everywhere else).
> It would be nice to have an unambiguous way to encode a number.
>
> On Tue, Oct 6, 2020 at 07:35 Eric Rescorla  wrote:
>
>> Hi folks,
>>
>> cTLS uses a bespoke varint format. Now that QUIC is nearly done, I
>> propose adopting their varint format.
>>
>> https://github.com/tlswg/draft-ietf-tls-ctls/pull/28
>>
>> Any objections?
>> -Ekr
>>
>> ___
>> 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#28: Converting cTLS to QUIC-style varints

[Eric Rescorla]

On Mon, Oct 5, 2020 at 6:38 PM Martin Thomson  wrote:

> Oh, I consider that to be a feature.  One that I exploit.  It's sometimes
> awkward to build a structure then prepend a length that has a
> variable-length encoding.  If you know the maximum length, the varint
> encoding allows you to avoid having to move memory.
>
> That said, cTLS won't authenticate both the value and the specific
> encoding of numeric values as the varint encoding is erased.  I don't
> consider that to be a serious problem, but it means that cTLS transcripts
> can't be directly compared.  I would note that in the draft: people
> shouldn't be processing cTLS messages that way, but they might be surprised
> to learn of this.
>

You could fix this by requiring the minimal encoding, right?

-Ekr


> On Tue, Oct 6, 2020, at 12:31, Marten Seemann wrote:
> > One thing that’s a bit annoying about QUIC’s variant format is that
> > there are multiple ways to encode a number. This has led to some
> > complications in the specification (e.g. QUIC requires you to use the
> > minimal encoding for frame types, but allows all encodings everywhere
> > else).
> > It would be nice to have an unambiguous way to encode a number.
> >
> > On Tue, Oct 6, 2020 at 07:35 Eric Rescorla  wrote:
> > > Hi folks,
> > >
> > > cTLS uses a bespoke varint format. Now that QUIC is nearly done, I
> propose adopting their varint format.
> > >
> > > https://github.com/tlswg/draft-ietf-tls-ctls/pull/28
> > >
> > > Any objections?
> > > -Ekr
> > >
> > > ___
> > > 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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Un-deprecating everything TLS 1.2

[Christopher Patton]

I agree that the HRR code path is hard to reason about, but I don't really
see an attack here. Is it your contention that the HRR code path leads to
an attack not accounted for by existing proofs?

I don't think this is likely. One way to think about this problem is as
follows [1]. Given an attacker that exploits the HRR code path, can you
efficiently construct an attacker that exploits a version of the protocol
without the HRR code path implemented? If the answer is "yes", and if we
assume the protocol is secure *without* the HRR code path implemented (as
asserted by a proof of security, say), it must be case that the protocol is
also secure *with* the HRR code path implemented.

Although I haven't studied this problem specifically ---  Dowling et al.
appear to address this problem, if only implicitly --- my intuition is that
the answer is "yes". The reason, loosely, is that the HRR code path doesn't
appear to depend on any ephemeral or long-term secret key material used by
the server for the core handshake. In particular, it doesn't depend on the
server's key share or signing key. This means that the adversary can
"simulate" any computation involving the HRR code path in its head, without
interacting with a real server. This observation ought to yield the
reduction I described above. Perhaps the spec is vague here, but if you
study any one of the high quality implementations that exist (openSSL,
boringSSL, NSS, Go's crypto/tls just to name a few), it won't be hard to
convince yourself that the HRR code path doesn't depend on secrets used in
the core handshake.


Chris P.

[1] https://eprint.iacr.org/2020/573

On Mon, Oct 5, 2020 at 2:47 PM Michael D'Errico  wrote:

> On 10/5/20 10:21, Christopher Patton wrote:
> > A couple pointers for getting started:
>
> Thank you for providing these links!  I'm going through
> the first one now and will note that it does not even
> mention the HelloRetryRequest message.  So while I am
> confident there has been quite a bit of study of a
> ClientHello -> ServerHello handshake, there may not
> have been much study of ClientHello1 -> HelloRetryRequest
> -> ClientHello2 -> ServerHello handshakes.
>
> I'm especially concerned about the fact that a "stateless"
> server does not even remember what the ClientHello1 or
> HelloRetryRequest messages were when it receives the
> second ClientHello.  Load-balanced data centers seem to
> do this based on some of the discussion I've had this
> week.
>
> The protocol handles the missing ClientHello1 message by
> replacing it with hash-of-ClientHello1, but then you're
> supposed to rely on the client to tell you this value in
> its ClientHello2.  Even if nothing funny is happening,
> how is the (stateless) server supposed to put the
> HelloRetryRequest message in the Transcript-Hash?  Where
> does it get this value from if it's not also somehow in
> the "cookie" (which is how the client reminds the server
> of hash-of-ClientHello1)?
>
> And how would you put the HelloRetryRequest message into
> the cookie extension when the cookie itself is a part of
> the HelloRetryRequest?
>
> Just trying to imagine the code I'd have to write to do
> this correctly makes my head spin:
>
>0)  [disable "TCP Fast Open" so I don't do lots of
>processing without knowing there's a routable
>address associated with the client]
>
>1)  receive ClientHello1
>
>2)  generate HelloRetryRequest message without cookie
>
>3)  package ClientHello1 and HelloRetryRequest-minus-
>cookie into a data structure, encrypt + MAC to
>create a cookie
>
>4)  insert the cookie into the HelloRetryRequest,
>remembering to update the length of the extensions
>
>5)  send HelloRetryRequest (with cookie) to client
>
>6)  erase all memory of what just happened!!!
>
>7)  receive ClientHello2
>
>8)  ensure it has a cookie extension (well I should
>at least remember the fact that I already sent a
>HelloRetryRequest and not be completely stateless,
>right?  Otherwise the client may be able to send
>many ClientHelloN's without a cookie)
>
>9)  check MAC on the cookie and if it's valid, decrypt
>it to determine the contents of ClientHello1 and
>the HelloRetryRequest (without cookie) messages
>
>10) MAKE SURE ClientHello2 is valid according to what
>was received in ClientHello1 (RFC 8446 has a list
>of things a client is allowed to do; I would want
>to check all of them, so a hash of ClientHello1
>is inadequate in my opinion).  This seems to be a
>necessary thing to do even for stateful servers.
>
>11) Recreate the actual HelloRetryRequest message
>that was sent to the client by putting the cookie
>into HRR-minus-cookie (in the same place within
>the list of extensions as was already done in step
>4, but since we threw it away, do it again)
>
>12) Hash the ClientHello1 and add this has

Re: [TLS] PR#28: Converting cTLS to QUIC-style varints

[Salz, Rich]

Can you just say “QUIC rules but use the minimum possible length”?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR#28: Converting cTLS to QUIC-style varints

[Marten Seemann]

In that case, why use QUIC's encoding at all? It would just put the burden
on the receiver to check that the minimal encoding was used.
Would it instead make more sense to modify QUIC's encoding, such that the
2-byte encoding doesn't encode the numbers from 0 to 16383, but the numbers
from 64 to (16383 + 64), and equivalently for 4 and 8-byte encodings?

On Tue, Oct 6, 2020 at 9:22 AM Salz, Rich  wrote:

> Can you just say “QUIC rules but use the minimum possible length”?
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR#28: Converting cTLS to QUIC-style varints

[Eric Rescorla]

I don't have a strong opinion on whether to require a minimal encoding, but
if we're not going to use QUIC's encoding as-is, then I would rather stick
with the existing scheme, which has twice as large a range for the 1 byte
encoding and is thus more compact for a range of common cases.

-Ekr


On Mon, Oct 5, 2020 at 7:31 PM Marten Seemann 
wrote:

> In that case, why use QUIC's encoding at all? It would just put the burden
> on the receiver to check that the minimal encoding was used.
> Would it instead make more sense to modify QUIC's encoding, such that the
> 2-byte encoding doesn't encode the numbers from 0 to 16383, but the numbers
> from 64 to (16383 + 64), and equivalently for 4 and 8-byte encodings?
>
> On Tue, Oct 6, 2020 at 9:22 AM Salz, Rich  wrote:
>
>> Can you just say “QUIC rules but use the minimum possible length”?
>>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR#28: Converting cTLS to QUIC-style varints

[Christian Huitema]

1994 called. It wanted to talk about distinguished encoding rules.

On 10/5/2020 8:08 PM, Eric Rescorla wrote:
> I don't have a strong opinion on whether to require a minimal
> encoding, but if we're not going to use QUIC's encoding as-is, then I
> would rather stick with the existing scheme, which has twice as large
> a range for the 1 byte encoding and is thus more compact for a range
> of common cases.
>
> -Ekr
>
>
> On Mon, Oct 5, 2020 at 7:31 PM Marten Seemann  > wrote:
>
> In that case, why use QUIC's encoding at all? It would just put
> the burden on the receiver to check that the minimal encoding was
> used.
> Would it instead make more sense to modify QUIC's encoding, such
> that the 2-byte encoding doesn't encode the numbers from 0 to
> 16383, but the numbers from 64 to (16383 + 64), and equivalently
> for 4 and 8-byte encodings?
>
> On Tue, Oct 6, 2020 at 9:22 AM Salz, Rich  > wrote:
>
> Can you just say “QUIC rules but use the minimum possible length”?
>
>
> ___
> 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#28: Converting cTLS to QUIC-style varints

[Rob Sayre]

On Mon, Oct 5, 2020 at 9:59 PM Christian Huitema 
wrote:

> 1994 called. It wanted to talk about distinguished encoding rules.
>

Could you expand on this idea?

I am not sure what you mean, because most things from circa 1994 are pretty
naive, to my eye.

thanks,
Rob




> On 10/5/2020 8:08 PM, Eric Rescorla wrote:
>
> I don't have a strong opinion on whether to require a minimal encoding,
> but if we're not going to use QUIC's encoding as-is, then I would rather
> stick with the existing scheme, which has twice as large a range for the 1
> byte encoding and is thus more compact for a range of common cases.
>
> -Ekr
>
>
> On Mon, Oct 5, 2020 at 7:31 PM Marten Seemann 
> wrote:
>
>> In that case, why use QUIC's encoding at all? It would just put the
>> burden on the receiver to check that the minimal encoding was used.
>> Would it instead make more sense to modify QUIC's encoding, such that the
>> 2-byte encoding doesn't encode the numbers from 0 to 16383, but the numbers
>> from 64 to (16383 + 64), and equivalently for 4 and 8-byte encodings?
>>
>> On Tue, Oct 6, 2020 at 9:22 AM Salz, Rich  wrote:
>>
>>> Can you just say “QUIC rules but use the minimum possible length”?
>>>
>>
> ___
> TLS mailing listTLS@ietf.orghttps://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] PR#28: Converting cTLS to QUIC-style varints

[Hannes Tschofenig]

Hi Ekr,

I had a chat with Richard about this and this change makes a lot of sense 
(particularly since the current cTLS draft only defines the encoding of varints 
up to 3 bytes).

In the work on QUIC did you discuss the ability to make the encoding such that 
there are no ways to express a number in two different ways, as shown in your 
example with the single byte 25 decoding to 37 and the two byte sequence 40 25?

Ciao
Hannes



From: TLS  On Behalf Of Eric Rescorla
Sent: Tuesday, October 6, 2020 3:38 AM
To: Marten Seemann 
Cc:  
Subject: Re: [TLS] PR#28: Converting cTLS to QUIC-style varints

Yeah, I'm certainly sympathetic to this. TBH, from an aesthetic perspective I 
prefer what's in cTLS now (though it had the same property) but I figured that 
some consistency was nice.

-Ekr



On Mon, Oct 5, 2020 at 6:31 PM Marten Seemann 
mailto:martenseem...@gmail.com>> wrote:
One thing that’s a bit annoying about QUIC’s variant format is that there are 
multiple ways to encode a number. This has led to some complications in the 
specification (e.g. QUIC requires you to use the minimal encoding for frame 
types, but allows all encodings everywhere else).
It would be nice to have an unambiguous way to encode a number.

On Tue, Oct 6, 2020 at 07:35 Eric Rescorla 
mailto:e...@rtfm.com>> wrote:
Hi folks,

cTLS uses a bespoke varint format. Now that QUIC is nearly done, I propose 
adopting their varint format.

https://github.com/tlswg/draft-ietf-tls-ctls/pull/28

Any objections?
-Ekr

___
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] PR#28: Converting cTLS to QUIC-style varints

[Martin Thomson]

On Tue, Oct 6, 2020, at 17:36, Hannes Tschofenig wrote:
> In the work on QUIC did you discuss the ability to make the encoding 
> such that there are no ways to express a number in two different ways, 
> as shown in your example with the single byte 25 decoding to 37 and the 
> two byte sequence 40 25? 

For QUIC, where the performance impact of serialization and parsing was 
considered important, the additional cost involved was a little higher than I 
think some people wanted.  It also makes the encoding more complex.

A "distinguished" or canonical encoding wasn't critical there.  It's probably 
not critical here either.

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