Re: [TLS] Working Group Last Call for SSLKEYLOG File

[Benjamin Kaduk]

On Wed, Mar 13, 2024 at 09:55:10AM +1100, Martin Thomson wrote:
> 
> 
> On Wed, Mar 13, 2024, at 08:39, Stephen Farrell wrote:
> 
> > Another thought occurred to me that I don't recall being mentioned
> > before: given we're defining a mime type, that suggests sending
> > these files by mail or in an HTTP response. Doing that could
> > be leaky, [...]
> 
> I see equal opportunity for good things (detecting keylogfiles, deleting 
> them, generating a warning), than bad as a result of writing this down.  See 
> also RFC 8959 (which the IETF did not publish, which I concede undermines my 
> position somewhat...)

I see RFC 8959 as being in the IETF RFC stream (not ISE).

-Ben

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

Re: [TLS] FW: New Version Notification for draft-mattsson-tls-super-jumbo-record-limit-01.txt

[Benjamin Kaduk]

Hi John,

I confess that my first impression was "eww, extensions with side effects on
other extensions, that sounds super finicky to implement correctly".

But actually reading in further, it seems more that the guiding principle is
instead "only have one way to do a thing", in this case to communicate
the maximum record size an endpoint is prepared to receive.
That said, it's still changing the semantics of an existing field, which
incurs a requirement to survey the compatibility with existing
implementations.  I see that RFC 8449 does carve out a way for endpoints
to send larger values if "explicitly allowed by such a future version or
extension.  A server MUST NOT enforce this restriction" so in theory we
should be okay, but we still need to actually check.

I also note that the semantics of record_size_limit per RFC 8449 are to
apply to the plaintext length, so I think it actually is weird and
overly complicated for your draft to propose that the negotiated length
will now be of the ciphertext length.

-Ben

On Mon, Feb 26, 2024 at 08:59:20AM +, John Mattsson wrote:
>Hi,
> 
> 
> 
>We just submitted version -01 of “Large Record Sizes for TLS and DTLS”.
>Michael Tüxen is a new co-author, the extension has been renamed to the
>more mundane “large_record_size" and is now a flag extension. The flag
>extension is now used together with "record_size_limit" to allow
>negotiation of maximum record size, not just a fixed 2^16 – 1 bytes.
> 
> 
> 
>The use for record sizes larger than 2^14 has been discussed in TSVWG for
>use in DTLS over SCTP and DTLS in SCTP. Large record sizes would be
>beneficial in several of the discussed solutions to remove limitation or
>to increase performance.
> 
> 
> 
>We would like to present draft-mattsson-tls-super-jumbo-record-limit-01 in
>Brisbane.
> 
> 
> 
>Cheers,
> 
>John Preuß Mattsson
> 
> 
> 
>From: internet-dra...@ietf.org 
>Date: Monday, 26 February 2024 at 09:34
>To: John Mattsson , Michael Tüxen
>, Hannes Tschofenig ,
>Hannes Tschofenig , John Mattsson
>, Michael Tuexen 
>Subject: New Version Notification for
>draft-mattsson-tls-super-jumbo-record-limit-01.txt
> 
>A new version of Internet-Draft
>draft-mattsson-tls-super-jumbo-record-limit-01.txt has been successfully
>submitted by John Preuß Mattsson and posted to the
>IETF repository.
> 
>Name: draft-mattsson-tls-super-jumbo-record-limit
>Revision: 01
>Title:Large Record Sizes for TLS and DTLS
>Date: 2024-02-26
>Group:Individual Submission
>Pages:6
>URL: 
>
> [1]https://www.ietf.org/archive/id/draft-mattsson-tls-super-jumbo-record-limit-01.txt
>Status:  
>
> [2]https://datatracker.ietf.org/doc/draft-mattsson-tls-super-jumbo-record-limit/
>HTML:
>
> [3]https://www.ietf.org/archive/id/draft-mattsson-tls-super-jumbo-record-limit-01.html
>HTMLized:
>
> [4]https://datatracker.ietf.org/doc/html/draft-mattsson-tls-super-jumbo-record-limit
>Diff:
>
> [5]https://author-tools.ietf.org/iddiff?url2=draft-mattsson-tls-super-jumbo-record-limit-01
> 
>Abstract:
> 
>   RFC 8449 defines a record size limit extension for TLS and DTLS
>   allowing endpoints to negotiate a record size limit smaller than the
>   protocol-defined maximum record size, which is around 2^14 bytes.
>   This document specifies a TLS flag extension to be used in
>   combination with the record size limit extension allowing endpoints
>   to use a record size limit larger than the protocol-defined maximum
>   record size, but not more than about 2^16 bytes.
> 
>The IETF Secretariat
> 
> Links:
> 1. 
> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-mattsson-tls-super-jumbo-record-limit-01.txt__;!!GjvTz_vk!RN5AZozXiNHDvG1fISqtqphUnczlXKWqr5U05s9TIuk_wy3yvUBi4iNbt70acVtcaAuZ6vK2IcBMZbSMLoBVi5PQtjvw8A$
> 2. 
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-mattsson-tls-super-jumbo-record-limit/__;!!GjvTz_vk!RN5AZozXiNHDvG1fISqtqphUnczlXKWqr5U05s9TIuk_wy3yvUBi4iNbt70acVtcaAuZ6vK2IcBMZbSMLoBVi5MOtgMACw$
> 3. 
> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-mattsson-tls-super-jumbo-record-limit-01.html__;!!GjvTz_vk!RN5AZozXiNHDvG1fISqtqphUnczlXKWqr5U05s9TIuk_wy3yvUBi4iNbt70acVtcaAuZ6vK2IcBMZbSMLoBVi5NSq7RMpA$
> 4. 
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-mattsson-tls-super-jumbo-record-limit__;!!GjvTz_vk!RN5AZozXiNHDvG1fISqtqphUnczlXKWqr5U05s9TIuk_wy3yvUBi4iNbt70acVtcaAuZ6vK2IcBMZbSMLoBVi5O0NTWNIQ$
> 5. 
> https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-mattsson-tls-super-jumbo-record-limit-01__;!!GjvTz_vk!RN5AZozXiNHDvG1fISqtqphUnczlXKWqr5U05s9TIuk_wy3yvUBi4iNbt70acVtcaAuZ6vK2IcBMZbSMLoBVi5Phx4rvmg$

> ___
> TLS mailing list
> TLS@ietf.org
> https://urld

Re: [TLS] [Errata Held for Document Update] RFC8446 (5682)

[Benjamin Kaduk]

I think if the errata report is moved back into the "reported" state by the RFC 
Editor staff, the AD should be able to edit the report to reflect the intent as 
opposed to having the diff appear.

-Ben

On Tue, Jan 16, 2024 at 07:07:19PM -0800, RFC Errata System wrote:
> The following errata report has been held for document update 
> for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". 
> 
> --
> You may review the report below and at:
> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid5682__;!!GjvTz_vk!T2x_YvOjybcaxb8hARC3CW6xdOhGeq2BD-cjxoPyutXUwQp_f3O3PfnITevFE1EaDkGlyknuPtDLnj4boiBQ1w$
>  
> 
> --
> Status: Held for Document Update
> Type: Technical
> 
> Reported by: Richard Barnes 
> Date Reported: 2019-04-01
> Held by: Paul Wouters (IESG)
> 
> Section: 4.3.2, B.3.2
> 
> Original Text
> -
> --- rfc8446.txt   2018-08-10 20:12:08.0 -0400
> +++ rfc8446.erratum.txt   2019-04-01 15:44:54.0 -0400
> @@ -3341,7 +3341,7 @@
>  
>struct {
>opaque certificate_request_context<0..2^8-1>;
> -  Extension extensions<2..2^16-1>;
> +  Extension extensions<0..2^16-1>;
>} CertificateRequest;
>  
>  
> @@ -7309,7 +7309,7 @@
>  
>struct {
>opaque certificate_request_context<0..2^8-1>;
> -  Extension extensions<2..2^16-1>;
> +  Extension extensions<0..2^16-1>;
>} CertificateRequest;
>  
>  
> 
> 
> Corrected Text
> --
> --- rfc8446.txt   2018-08-10 20:12:08.0 -0400
> +++ rfc8446.erratum.txt   2019-04-01 15:44:54.0 -0400
> @@ -3341,7 +3341,7 @@
>  
>struct {
>opaque certificate_request_context<0..2^8-1>;
> -  Extension extensions<2..2^16-1>;
> +  Extension extensions<0..2^16-1>;
>} CertificateRequest;
>  
>  
> @@ -7309,7 +7309,7 @@
>  
>struct {
>opaque certificate_request_context<0..2^8-1>;
> -  Extension extensions<2..2^16-1>;
> +  Extension extensions<0..2^16-1>;
>} CertificateRequest;
>  
>  
> 
> 
> Notes
> -
> The length of this vector can never 2.  It is either 0, if the vector is 
> empty, or >=4, if the vector has at least one extension.  Nothing elsewhere 
> in the spec requires a non-zero number of extensions here, so this syntax 
> should allow a zero-length vector.
> 
> Paul Wouters (AD): Richard meant the diff to be the fix, not the 
> original/corrected text. The diff is not in the RFC itself. There are two 
> places in the mentioned sections that need this one liner fix.
> 
> --
> 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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!T2x_YvOjybcaxb8hARC3CW6xdOhGeq2BD-cjxoPyutXUwQp_f3O3PfnITevFE1EaDkGlyknuPtDLnj70kj7-uw$
>  

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

Re: [TLS] Key Update for TLS/DTLS 1.3

[Benjamin Kaduk]

On Thu, Jan 04, 2024 at 11:42:13AM +, Tschofenig, Hannes wrote:
>Hi all,
> 
> 
> 
>we have just submitted a draft that extends the key update functionality
>of TLS/DTLS 1.3.
> 
>We call it the “extended key update” because it performs an ephemeral
>Diffie-Hellman as part of the key update.
> 
> 
[...]
> 
> 
>Here is the link to the draft:
> 
>
> [1]https://datatracker.ietf.org/doc/draft-tschofenig-tls-extended-key-update/

A few thoughts from a quick read (to supplement the good comments already 
received):

- I'm not sure that the current condition "can be sent by either peer after it 
has sent a Finished message" will work quite right for the DTLS case; I think 
that you'd need to also know that your Finished has been processed before 
sending EKU, in order to ensure that the peer will accept it.

- I'd probably drop the "perfect" from "perfect forward secrecy" -- you already 
quote the bit from RFC 9325 that uses just "forward secrecy" as the primary 
term and I don't see much reason to diverge from that.

- The discussion of truncation attacks near the end of §4.1 doesn't seem quite 
right w.r.t. DTLS, in that DTLS is always going to be susceptible to truncation 
attacks (but I do think that the requirement you propose should still be 
enforced).

- The prose discussion of the key schedule should probably get tweaked a bit; 
it makes it sound as if application_traffic_secret_N is not used at all (it's 
currently put in as the "messages" parameter to Derive-Secret(), if I'm reading 
correctly) and that the dh-secret is used directly in HKDF-Expand-Label() 
(which would be misuse since it's not uniformly random and needs an 
HKDF-Extract first, as is shown in the actual figure).

- I'm not sure about using application_traffic_secret_N as the "messages" input 
to Derive-Secret() -- that would seem to imply that we hash it as a transcript 
hash???  Why not use it as HKDF-Extract input alongside dh-secret?

- I'm not sure I'd put something about hybrid key exchange in at this point, 
and IIRC the concatenation secret combiner is not known to be the best choice 
of secret combiner.

Thanks,

Ben

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

Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'

[Benjamin Kaduk]

On Tue, Jan 02, 2024 at 07:17:44PM -0800, Eric Rescorla wrote:
>On Tue, Jan 2, 2024 at 5:02 PM Rob Sayre <[1]say...@gmail.com> wrote:
> 
>  It might be better to describe TLS 1.2 as "overtaken by events". If you
>  want to use CSS Grid or Swift UI (name any newish thing), you'll find
>  yourself with a stack that supports TLS 1.3, so there's no need to
>  bother with TLS 1.2 in those cases. Turning off TLS 1.2 is sometimes a
>  good idea, because that traffic is composed of undesirable bots in many
>  cases.
>  I know people also work on things that are old, but it seems ok to call
>  them really old, because that is true. No one seems to disagree with
>  this point in the draft: "TLS 1.3 [TLS13] is also in widespread use and
>  fixes most known deficiencies with TLS 1.2".
>  If you think this draft is so strict that it will be ignored, you have
>  nothing to worry about.
> 
>The issue I am concerned about is that:
>1. Implementors who do not want to upgrade to TLS 1.3 will implement new
>cipher suites
>2. IANA will refuse to register the new cipher suites
>With the result being potential code point collisions.

I share this concern.

-Ben

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

Re: [TLS] Questions about RFC 5929 (channel bindings)

[Benjamin Kaduk]

On Tue, Dec 26, 2023 at 04:28:52PM +0200, Ilari Liusvaara wrote:
> On Tue, Dec 26, 2023 at 09:48:32PM +0900, Kazu Yamamoto (山本和彦) wrote:
> > Hi,
> > 
> > I'm trying to implement channel bindings defined RFC 5929.
> > I have three questions:
> 
> Also note RFC 9266. That defines how to perform SCRAM/GSS-API with TLS
> 1.3.

I'll note that during the creation of RFC 9266 the presumption was that
the relevant channel binding simply was not defined for TLS 1.3 at all, and
should not be attempted until there was an adequate specification for how to do
so.

> 
> > Q2) Can "tls-server-end-point" apply to TLS 1.3?
> 
> It could be appiled, but that is probably not a good idea.

I agree (on both counts).

> For SCRAM and GSS-API, "tls-server-end-point" is not used in TLS 1.3.
> 
> 
> > Q3) If the answer to Q2 is yes, which part is hashed?
> > 
> > RFC 8446 defines Certificate as:
> > 
> >  struct {
> >   opaque certificate_request_context<0..2^8-1>;
> >   CertificateEntry certificate_list<0..2^24-1>;
> >   } Certificate;
> > 
> >
> >hash(Certificate) or hash(Handshake:Certificate) or
> >hash(certificate_list)?
> 
> I don't think it is specified anywhere, but I think the most reasonable
> thing is neither of those, but instead re-encoding the certificate_list
> into TLS 1.2 form and hashing that. So the resulting binding values are
> compatible with TLS 1.2.

My reading of 5929 is that you are supposed to just hash the DER of the X.509
cert, not any TLS framing (but I did not check what has been implemented
anywhere), so no re-encoding would be needed, just extracting out the
right bits of cert_data (TLS 1.3) or ASN.1Cert (TLS 1.2).

But if there is any real question of ambiguity it seems that a tiny RFC is 
called for.

-Ben

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

Re: [TLS] Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3

[Benjamin Kaduk]

On Tue, Oct 24, 2023 at 10:12:56PM -0400, David Benjamin wrote:
>Additionally I want to emphasize that, because of the negotiation order
>between versions and client certificates, there is no way to do an
>incremental transition here. Saying deployments stick with 1.2 not only
>impacts the relevant hardware but also *any other connections that the
>server makes*. Essentially the server cannot enable TLS 1.3 until *every*
>client has stopped using one of these PSS-incapable signers. This is not a
>good transition plan.

I think we should probably think out the transition plan here a bit more.
Sure, if we can have updated clients offer new SignatureSchemes and the server
notice that to let them use TLS 1.3.  But how does the server get to a place
where it can use TLS 1.3 with every client that offers it?  It seems like it
has to know that all clients with old hardware tokens have updated, which would
require knowing about and tracking exactly which clients those are, since other
clients would not be sending the new SignatureSchemes in the first place.  I
see this getting a small win for the legacy clients but no improvement for
other clients or the server's default behavior.  Am I missing something?

-Ben

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

Re: [TLS] multi-identity support in RFC 8446

[Benjamin Kaduk]

On Thu, Mar 02, 2023 at 04:29:11AM +, Peter Gutmann wrote:
> Chuck Lever III  writes:
> 
> >We're implementing TLSv1.3 support for PSK and note there is a capability in
> >the PSK extension described in S 4.2.11 for sending a list of identities. We
> >don't find support for a list of alternate identities implemented in user
> >space TLS libraries such as GnuTLS or OpenSSL. Is there a known reason for
> >that omission?
> 
> If it's the same as similar locations in previous versions of TLS where it's
> possible to specify a list of X instead of just an X then it could be because
> no-one has any idea why you'd specify a list of X, or what to do with it if
> one does turn up.  There are several fields where, in the past, we've had
> users ask what to do with them and it turned out, after some testing, that the
> answer is "whatever you want" because the other side pays no attention
> whatsoever to what's in there.

If you would like to use a PSK for authentication a full handshake but also 
have the option of doing resumption, you would need to offer two distinct PSKs 
in order to ensure that a handshake would succeed.
The only reasons I can think of to offer more than two would be somewhat 
exotic, where you are (e.g.) binding application-layer semantics to the PSK 
identity.

-Ben

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

Re: [TLS] Getting started, clock not set yet

[Benjamin Kaduk]

On Thu, Aug 11, 2022 at 12:35:23PM -0700, Christian Huitema wrote:
> 
> Isn't the ANIMA WG working on these scenarios? If there is a formal
> "enrollment" process for adding a device to a network, that process could
> include setting the time, and possibly performing updates. I say "possibly"
> here, because in scenarios like "disaster recovery", the local network may
> not have global connectivity. But even so, setting the time during
> enrollment seems logical.

https://www.rfc-editor.org/rfc/rfc8995.html#section-2.6 seems to already
have some discussion of how to handle the lack of a(n accurate) real-time
clock, yes.

-Ben

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

Re: [TLS] Getting started, clock not set yet

[Benjamin Kaduk]

On Tue, Aug 09, 2022 at 04:12:37PM -0700, Eric Rescorla wrote:
> n Tue, Aug 9, 2022 at 4:08 PM Benjamin Kaduk  wrote:
> 
> > On Tue, Aug 09, 2022 at 03:59:01PM -0700, Eric Rescorla wrote:
> > >
> > > Be that as it may, the browsers generally require conformance to the BRs
> > > (see, for
> > > instance
> > >
> > https://urldefense.com/v3/__https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/__;!!GjvTz_vk!UPmxyrKmaL10wJG8moM9lRB_dy37NNBtZYo3xVxxNx1_6JSsjXC25--ngicIeypX3KAVLzA$
> >
> > > S 2.3,
> > >
> > https://urldefense.com/v3/__https://www.chromium.org/Home/chromium-security/root-ca-policy/__;!!GjvTz_vk!UPmxyrKmaL10wJG8moM9lRB_dy37NNBtZYo3xVxxNx1_6JSsjXC25--ngicIeypXz_sK-Pc$
> >  S 1)
> > > so what the BRs say is relevant in this discussion.
> >
> > While it seems almost inevitable that the Web PKI will be used for some
> > deployments of NTS, it also seems that NTS as a protocol is quite
> > untethered to
> > browser behavior or the Web PKI.  So while I agree that the CABF BRs are
> > relevant, they probably ought not be treated as the sole authority.
> >
> 
> Fair enough. I would make several points:
> 
> 1. Peter's message was not qualified to NTS. He wrote
> "For commercial CAs, the expiry time is a billing mechanism, not a security
> mechanism. "
> 
> So I was attempting to respond to the bigger picture.

Ok.

> 2. It seems quite likely that many of the NTS certificates will be from
> WebPKI CAs,
> just because that's what's easy to get, and so you can't count on them
> providing
> revocation after expiry.

Agreed, that's my "almost inevitable".

> 3. Are you aware of some other set of rules for certificate issuance that
> require
> revocation after the certificate has expired?

No.
And to be honest I would be somewhat surprised to learn of one, since
one of the big gains of having an expiration at all (vs just tracking
revocation information) is to simplify the database of revocation information
by allowing for pruning after expiry.  Perhaps some sort of "official records"
system might need it, but that's pure speculation.

Private parties not part of a broader PKI can of course use whatever policies
and procedures they want.

-Ben

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

Re: [TLS] Getting started, clock not set yet

[Benjamin Kaduk]

On Tue, Aug 09, 2022 at 03:59:01PM -0700, Eric Rescorla wrote:
> 
> Be that as it may, the browsers generally require conformance to the BRs
> (see, for
> instance
> https://urldefense.com/v3/__https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/__;!!GjvTz_vk!UPmxyrKmaL10wJG8moM9lRB_dy37NNBtZYo3xVxxNx1_6JSsjXC25--ngicIeypX3KAVLzA$
>   
> S 2.3,
> https://urldefense.com/v3/__https://www.chromium.org/Home/chromium-security/root-ca-policy/__;!!GjvTz_vk!UPmxyrKmaL10wJG8moM9lRB_dy37NNBtZYo3xVxxNx1_6JSsjXC25--ngicIeypXz_sK-Pc$
>S 1)
> so what the BRs say is relevant in this discussion.

While it seems almost inevitable that the Web PKI will be used for some
deployments of NTS, it also seems that NTS as a protocol is quite untethered to
browser behavior or the Web PKI.  So while I agree that the CABF BRs are
relevant, they probably ought not be treated as the sole authority.

-Ben

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

Re: [TLS] What is "completed handshake"?

[Benjamin Kaduk]

On Mon, Aug 08, 2022 at 03:18:22PM +0200, Dmitry Belyavsky wrote:
> Dear colleagues,
> 
> RFC 8446 refers to "completed handshake" as a prerequisite for some
> messages. But looking for the word "completed", I don't see any definition.
> Could you please point me to it (and probably, include this definition into
> rfc8446-bis)?

https://datatracker.ietf.org/doc/html/rfc9001#section-4.1.1 has a nice
concise definition that I believe to be applicable to "native" TLS 1.3
just as well as it to the embedding of the TLS 1.3 handshake layer into
the QUIC protocol.

-Ben

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

Re: [TLS] Before we PQC... Re: PQC key exchange sizes

[Benjamin Kaduk]

On Sat, Aug 06, 2022 at 04:00:59AM -0700, Rob Sayre wrote:
> On Fri, Aug 5, 2022 at 10:15 PM Benjamin Kaduk  wrote:
> 
> >
> > It's annoying to the attacker when they have to use their expensive and
> > finicky
> > hardware once (or multiple times) for each individual message/exchange they
> > want to break,
> >
> 
> Well, I can agree with the term "expensive", but I'm not sure what you mean
> by "finicky". Are you saying they only work sometimes? It seems a bit
> hand-wavy to say that.

(Note: my Ph.D. is in theoretical (quantum) chemistry.)
Quantum mechanics is inherently a matter of probabilities and potential 
outcomes.
Current hardware relies on either being very cold, very isolated from the 
surroundings,
or both, to avoid unwanted coupling between qbits and the outside world that 
causes
decoherence.  Achieving the physics in a physical engineering matter is 
inherently finicky,
though you can build error-correction and robustness on top of it that helps.

> I've seen quantum computers before. They are room-sized, but not that big.
> I still find the term "quantum annoying" rather imprecise.

It's playing at the margins between theory and engineering practicality, so the
target is going to change over time.  I'm not surprised that this comes across
as having some level of imprecision.

-Ben

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

Re: [TLS] Before we PQC... Re: PQC key exchange sizes

[Benjamin Kaduk]

On Fri, Aug 05, 2022 at 07:16:06PM -0700, Rob Sayre wrote:
> On Fri, Aug 5, 2022 at 5:16 PM Sofía Celi  wrote:
> 
> > There is a notion of being 'quantum annoyant' to a quantum computer:
> >
> 
> I've encountered the term "quantum annoyant" a few times. Is there a
> precise definition that could be referenced? Maybe [0]?
> 
> I don't find the references I know of very satisfying, and I would
> translate "annoyant" to "doesn't actually work".
> 
> thanks,
> Rob
> 
> [0] 
> https://urldefense.com/v3/__https://eprint.iacr.org/2021/696.pdf__;!!GjvTz_vk!S_lXpy5HvfAfDJmtXdME2kuOOLXGTGz07_pqClIgY8ppVcZYu7Cf2WQ0K7YjyyOypKFppMI6NE_C$
>  

I think [0] is the reference (or at least very similar content) I've seen in 
previous discussions of this topic.

It's annoying to the attacker when they have to use their expensive and finicky
hardware once (or multiple times) for each individual message/exchange they
want to break, rather than being able to amortize the cost of running the
quantum computer across many protocol runs that are broken by that computer.
They'd have to be selective about what to decrypt (quickly), rather than just
getting "everything" -- while a QC does provide massive speedups, it does still
take some actual amount of time to run, and we can build protocols so that
the runtime of the QC is a practical constraint on the attacker's ability, even
if it is not necessarily a theoretical constraint on them.

-Ben

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

Re: [TLS] Before we PQC... Re: PQC key exchange sizes

[Benjamin Kaduk]

Hi Scott,

mutt+links can't cope with your text/html using [p class="MsoNormal" 
style="margin-left:.5in"] for quoting (and the text/plain multipart alternative 
is completely busted), so I have to trim PHB's original in most instances.

On Sat, Aug 06, 2022 at 03:18:31AM +, Scott Fluhrer (sfluhrer) wrote:
> 
> > I have the luxury of having 0 users. So I can completely redesign my 
> > architecture if needs be.
> 
> I would disagree; after all, we do have existing TLS 1.3 implementations.  I 
> believe it is important to avoid unnecessary changes, for two reasons:

PHB's use of the first-person singular implies he's talking about the 
mathematical mesh, not TLS at all.

> I’m trying to figure out what you’re saying; at least one of us is confused.  
> NIST asked for a Key Exchange Mechanism (KEM), and Kyber meets that 
> definition (which is essentially what you describe; both sides gets a shared 
> secret).  That is the functionality that TLS needs, and is the functionality 
> that NIST (and others) evaluated.  Yes, there are internal functions within 
> Kyber; no one is suggesting those be used directly.  And, yes, NIST might 
> tweak the precise definition of Kyber before it is formally approved; any 
> such tweak would be minor (and there might not be any at all); if they do 
> make such a change, it should not be difficult to modify any draft we put out 
> to account for that change.

I thought KEM expanded to "Key Encapsulation Mechanism" (viz RFC 9180).
Indeed, my understanding is that PHB's specific point is that it is *not* an 
exchange, and rather that the sender picks a key and the recipient just gets 
that key without contributing do it.
(Well, I think there is maybe also some bit in PHB's note that's quibbling 
about how the sender doesn't actually pick the key, and rather the local output 
of the KEM is the encapsulated blob plus the shared key, with the shared key 
not being an input to the KEM ... but I haven't read NIST's report yet and 
can't confirm or reject that assertion.)  I am reading PHB as saying that the 
"internal function" within Kyber that is an "actual KEM" is one that takes the 
shared key as input and produces the encapsulated blob as output (again, cannot 
confirm or reject).

> It was my understanding that TLS 1.3 didn’t do rekeys (ChangeCipherSuite).  
> Instead, the key agreement is done only at connection establishment time, and 
> could be broken into:
> 
>   *   Full negotiation (the client not having any context)
>   *   Resumption (0-RTT or 1-RTT) negotiation (where the client has some 
> secret data from a previous full negotiation)
> Because those are both fresh negotiations, I don’t see any alternative to 
> using a postquantum key exchange for both.

There's also KeyUpdate.
And the PSK handshake mode that's just psk_ke, not psk_dhe_ke.
But I don't think I understand PHB's proposed taxonomy yet, either.

-Ben

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

Re: [TLS] Authentication weaker in PSK-mode?

[Benjamin Kaduk]

On Wed, Jul 20, 2022 at 01:34:12PM +0200, Ben Smyth wrote:
> Authentication feels weaker in PSK-mode:
> 
> * A server proves possession of a (short-term) shared key,
> 
> whereas, with certificate-based authentication,
> 
> * A server proves possession of a (long-term) private key;
> 
> should we consider PSK-mode authentication weaker than certificate-based
> authentication?
> 
> PSK-mode cannot be bolstered with certificate-based authentication: "In TLS
> 1.3...either a PSK or a certificate is always used, but not both. Future
> documents may define how to use them together." Have any such documents
> emerged?

RFC 8773 does so.

-Ben

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

Re: [TLS] Can flags be responded to with an extension?

[Benjamin Kaduk]

Hi Ekr,

On Mon, May 09, 2022 at 08:56:26AM -0700, Eric Rescorla wrote:
> On Mon, May 9, 2022 at 8:43 AM Benjamin Kaduk  40akamai@dmarc.ietf.org> wrote:
> 
> > On Mon, May 09, 2022 at 06:10:43PM +0300, Yoav Nir wrote:
> > >
> > >
> > > > On 14 Apr 2022, at 1:51, Benjamin Kaduk  > 40akamai@dmarc.ietf.org> wrote:
> > > >
> > > > On Wed, Apr 13, 2022 at 10:56:49AM -0700, Eric Rescorla wrote:
> > > >> Consider the case where the client wants to offer some capability that
> > > >> the server then responds to with real data, rather than just an
> > > >> acknowledgement.
> > > >>
> > > >> For instance, supposing the SCT extension from RFC 6962 did not exist,
> > > >> the client would want to indicate support in CH and the server would
> > > >> send the SCT in CERT, but this extension would need to be non-empty
> > > >> and hence not a flag. draft-ietf-tls-tlsflags-09 seems a bit
> > > >> uncelar on this point (unless I'm missing it) but I think we
> > > >> should explicitly allow it.
> > > >
> > > > In my head this was already disallowed.  I couldn't swear to whether
> > > > we actually talked about it previously or not, though.
> > >
> > > I’m pretty sure we haven’t discussed this (or at least, I wasn’t in the
> > room).  In my head it’s also disallowed.  In the text, it’s not explicitly
> > disallowed, but the text does talk about response flags that are in flag
> > extensions, not about responses that are in other extensions or other
> > messages.  So implicitly disallowed?
> >
> > I think the description in the abstract of the target class of extension as
> > those "that carry no interesting information except the 1-bit indication
> > that a
> > certain optional feature is supported" also implicitly disallows response
> > bodies.
> >
> 
> Hmm... I don't think this is really the right approach at this stage.
> 
> The situation here is that the explicit text is ambiguous. If this were
> already an RFC, we would need to try to determine what it meant so that we
> could agree how implementations ought to be behaving. In that case, yes, we
> would look at this kind of language to attempt to resolve the ambiguity.
> 
> However, this is not an RFC and so our task is to make the specification as
> unambiguous as possible. At this stage, we should be asking what the
> *right* answer is, not what the one that most closely matches the current
> ambiguous text. My argument is that the right answer is the one that most

Yes.  You've convinced me that we need to be (more) explicit one way or the 
other.

Please treat my remark as a contribution to enumerating places in the document
that would need to change if we were to allow responses outside of the flags
extension.

-Ben

> closely embodies the broader goal of saving bandwidth for low-information
> signals, in this case the signal that the client could process a given
> server extension. So, yes, the client's extension contains no interesting
> information but the server's does, which, I think, is consistent with this
> text, even if, arguably, it's not the better reading.
> 
> I can certainly see arguments against forbidding this practice for
> technical reasons (e.g., simplicity), but, again, then the specification
> should just say so.
> 
> -Ekr

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

Re: [TLS] Can flags be responded to with an extension?

[Benjamin Kaduk]

On Mon, May 09, 2022 at 06:10:43PM +0300, Yoav Nir wrote:
> 
> 
> > On 14 Apr 2022, at 1:51, Benjamin Kaduk 
> >  wrote:
> > 
> > On Wed, Apr 13, 2022 at 10:56:49AM -0700, Eric Rescorla wrote:
> >> Consider the case where the client wants to offer some capability that
> >> the server then responds to with real data, rather than just an
> >> acknowledgement.
> >> 
> >> For instance, supposing the SCT extension from RFC 6962 did not exist,
> >> the client would want to indicate support in CH and the server would
> >> send the SCT in CERT, but this extension would need to be non-empty
> >> and hence not a flag. draft-ietf-tls-tlsflags-09 seems a bit
> >> uncelar on this point (unless I'm missing it) but I think we
> >> should explicitly allow it.
> > 
> > In my head this was already disallowed.  I couldn't swear to whether
> > we actually talked about it previously or not, though.
> 
> I’m pretty sure we haven’t discussed this (or at least, I wasn’t in the 
> room).  In my head it’s also disallowed.  In the text, it’s not explicitly 
> disallowed, but the text does talk about response flags that are in flag 
> extensions, not about responses that are in other extensions or other 
> messages.  So implicitly disallowed?

I think the description in the abstract of the target class of extension as
those "that carry no interesting information except the 1-bit indication that a
certain optional feature is supported" also implicitly disallows response
bodies.

-Ben

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

Re: [TLS] Can flags be responded to with an extension?

[Benjamin Kaduk]

On Wed, Apr 13, 2022 at 10:56:49AM -0700, Eric Rescorla wrote:
> Consider the case where the client wants to offer some capability that
> the server then responds to with real data, rather than just an
> acknowledgement.
> 
> For instance, supposing the SCT extension from RFC 6962 did not exist,
> the client would want to indicate support in CH and the server would
> send the SCT in CERT, but this extension would need to be non-empty
> and hence not a flag. draft-ietf-tls-tlsflags-09 seems a bit
> uncelar on this point (unless I'm missing it) but I think we
> should explicitly allow it.

In my head this was already disallowed.  I couldn't swear to whether
we actually talked about it previously or not, though.

-Ben

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

Re: [TLS] [response[ AD review of draft-ietf-tls-subcerts-11

[Benjamin Kaduk]

Hi Nick,

In full turnaround I of course failed to see *your* mail as it came in; my
apologies.

tl;dr: the now-posted -12 is good enough for me to initiate IETF LC.
Some additional notes inline.

On Tue, Mar 01, 2022 at 10:22:03AM -0500, Nick Sullivan wrote:
> TLSWG,
> 
> Benjamin Kaduk sent a review to the list of draft 11 of Delegated
> Credentials. Somehow I didn't get the email, so I'm restating his points
> here with responses. Ben, thanks for the thorough review. If there's
> consensus around my proposed responses to the changes, I'll put together an
> additional PR to go along with Benjamin's PR and submit a new draft version.
> 
> Nick
> 
> 
> >>>>>
> 
> Hi all,
> 
> Generally I like the shape this is in, but there's enough potentially in
> flux after this review that I'd like to clean things up with a revised I-D
> before I kick off the IETF LC.  I think my comments on §4.2 are the ones
> that are most likely to result in any significant discussion.
> 
> I made some (hopefully) editorial suggestions in a github PR, though
> a couple seemed borderline enough that I mention them here as well.
> (https://github.com/tlswg/tls-subcerts/pull/93)
> 
> Abstract
> 
> (editorial) There seems to be a large jump from the sentence that say
> the CA ultimately determines a lot about the certificate and the
> sentence describing the mechanism this document describes.  We might
> want to help the transition by also saying that the new mechanism
> partially overcomes/mitigates those limitations.
> 
> [NS]
> Proposed changes
> Before:
>The organizational separation between the operator of a TLS endpoint
>and the certification authority can create limitations.  For example,
>the lifetime of certificates, how they may be used, and the
>algorithms they support are ultimately determined by the
>certification authority.  This document describes a mechanism by
>which operators may delegate their own credentials for use in TLS,
>without breaking compatibility with peers that do not support this
>specification.
> 
> NEW:
>The organizational separation between the operator of a TLS endpoint
>and the certification authority can create limitations.  For example,
>the lifetime of certificates, how they may be used, and the
>algorithms they support are ultimately determined by the
>certification authority.  This document describes a mechanism to
>to overcome some of these limitations by enabling operators to
>delegate their own credentials for use in TLS without breaking
>compatibility with peers that do not support this specification.
> [/NS]
> 
> Section 1
> 
>   However, short-lived certificates need to be renewed more frequently
>   than long-lived certificates.  If an external CA is unable to issue a
>   certificate in time to replace a deployed certificate, the server
>   would no longer be able to present a valid certificate to clients.
> 
> (editorial) Most of the document carefully phrases things so that it
> does not presume that the DC holder is the TLS server (e.g., in this
> section we mostly talk about "server operator"s).  This chunk does
> not, and arguably the following paragraph as well.  I didn't come up
> with a different phrasing I liked so as to offer it in my PR, though.
> 
> [NS]
> In this section we are talking about traditional TLS deployments (without
> DCs or remote key operations) to motivate the document.  In
> these scenarios the certificate is typically deployed to server
> may introduce confusion to differentiate between server and certificate
> holder.  I don’t think there’s a useful change we can make that improves
> clarity.
> [/NS]

That makes sense to me as a reason for this section to be specific to
server DC usage.

> Section 3
> 
>   It was noted in [XPROT] that certificates in use by servers that
>   support outdated protocols such as SSLv2 can be used to forge
>   signatures for certificates that contain the keyEncipherment KeyUsage
>   ([RFC5280] section 4.2.1.3).  In order to prevent this type of cross-
>   protocol attack, we define a new DelegationUsage extension to X.509
>   that permits use of delegated credentials.  (See Section 4.2.)
> 
> If I understand correctly, the extension serves to prevent *existing*
> misconfigured servers from being leveraged in a cross-protocol attack to
> "sign" DCs usable for TLS 1.3.  As we discuss in §7.6, however, it does
> not prevent the attack when such a misconfigured server is given a new
> certificate that contains the extension (as might happen if a cert is
> shared across the TLS 1.2 and TLS 1.3 backends for a single service and
&g

Re: [TLS] dnssec_chain entry in IANA registry seems to be missing CT

[Benjamin Kaduk]

On Tue, Feb 22, 2022 at 08:27:02PM -0500, Shumon Huque wrote:
> On Wed, Feb 16, 2022 at 4:29 AM Ilari Liusvaara 
> wrote:
> 
> > I noticed that the "dnssec_chain" extension in the IANA registry lists
> > only "CH" in the "TLS 1.3" column. However, the extension sends its
> > response in the certificate message (section 2.2), so I think that
> > column should read "CH, CT".
> >
> 
> You are right, Ilari.
> 
> What's the process to get the IANA registry corrected?

It is probably "best" (for some definition of "best") to publish an RFC
that Updates: 9102 and has the revised directive to IANA.

Probably an errata report should be filed against RFC 9102 regardless.
IANA might be able to use the errata report without the updating RFC,
but you'd have to ask.

-Ben

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

Re: [TLS] tlsflags and "responses"

[Benjamin Kaduk]

On Mon, Feb 21, 2022 at 11:21:38AM +1100, Martin Thomson wrote:
> I missed this text in draft-ietf-tls-tlsflags:
> 
>A server that supports this extension and also supports at least one
>of the flag-type features that use this extension and that were
>declared by the ClientHello extension SHALL send this extension with
>the intersection of the flags it supports with the flags declared by
>the client.  
> 
> While sloppy on my part [1], I want to make it clear that this is a 
> show-stopper for me. Requiring an echo prevents a flag extension from 
> attaching semantics to a "response".
> 
> I agree with Ilari's earlier point that these should work just like 
> extensions.  If the server has no need to echo a flag, it should not be 
> required to do that.  That allows the flag value in a "response" to carry 
> semantics.

I think (but don't have a solid recollection) that this may have stemmed from a 
desire for the sender to know if the recipient supports flags at all.  But 
thinking about it now (and as Ekr's response suggests), so long as we don't 
allocate flags for existing extensions, there is not much useful to do with 
that information in cases where the extension semantics of the flag(s) in 
question don't require a response.

-Ben

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

[TLS] AD review of draft-ietf-tls-subcerts-11

[Benjamin Kaduk]

Hi all,

Generally I like the shape this is in, but there's enough potentially in
flux after this review that I'd like to clean things up with a revised I-D
before I kick off the IETF LC.  I think my comments on §4.2 are the ones
that are most likely to result in any significant discussion.

I made some (hopefully) editorial suggestions in a github PR, though
a couple seemed borderline enough that I mention them here as well.
(https://github.com/tlswg/tls-subcerts/pull/93)

Abstract

(editorial) There seems to be a large jump from the sentence that say
the CA ultimately determines a lot about the certificate and the
sentence describing the mechanism this document describes.  We might
want to help the transition by also saying that the new mechanism
partially overcomes/mitigates those limitations.

Section 1

   However, short-lived certificates need to be renewed more frequently
   than long-lived certificates.  If an external CA is unable to issue a
   certificate in time to replace a deployed certificate, the server
   would no longer be able to present a valid certificate to clients.

(editorial) Most of the document carefully phrases things so that it
does not presume that the DC holder is the TLS server (e.g., in this
section we mostly talk about "server operator"s).  This chunk does
not, and arguably the following paragraph as well.  I didn't come up
with a different phrasing I liked so as to offer it in my PR, though.

Section 3

   It was noted in [XPROT] that certificates in use by servers that
   support outdated protocols such as SSLv2 can be used to forge
   signatures for certificates that contain the keyEncipherment KeyUsage
   ([RFC5280] section 4.2.1.3).  In order to prevent this type of cross-
   protocol attack, we define a new DelegationUsage extension to X.509
   that permits use of delegated credentials.  (See Section 4.2.)

If I understand correctly, the extension serves to prevent *existing*
misconfigured servers from being leveraged in a cross-protocol attack to
"sign" DCs usable for TLS 1.3.  As we discuss in §7.6, however, it does
not prevent the attack when such a misconfigured server is given a new
certificate that contains the extension (as might happen if a cert is
shared across the TLS 1.2 and TLS 1.3 backends for a single service and
the TLS 1.2 implementation is unloved).  So maybe we should hedge our
language a bit from "prevent this type of cross-protocol attack".

Section 3.1

   *  X.509 semantics are very rich.  This can cause unintended
  consequences if a service owner creates a proxy certificate where
  the properties differ from the leaf certificate.  For this reason,
  delegated credentials have very restricted semantics that should
  not conflict with X.509 semantics.

In light of Peter's affirmation that proxy certs remain heavily used in grid
computing
(https://mailarchive.ietf.org/arch/msg/tls/AZQRnOtA-6Am7CM65HX4YSb_vdQ/), I
wonder if we want to make some statement to clarify that proxy certs are
still a useful tool in expert hands, even if the risk we describe is real.

Section 3.2

I put this in my PR as essentialy editorial, but copy the change here for
added visibility:

OLD:
   These two mechanisms can be complementary.  A server could use
   delegated credentials for clients that support them, while using
   [KEYLESS] to support legacy clients.  The private key for a delegated
   credential can be used in place of a certificate private key, so it
   is important that the Front-End and Back-End are parties with a
   trusted relationship.

NEW:
   These two mechanisms can be complementary.  A server could use
   delegated credentials for clients that support them, while using a
   server-side mechanism to support legacy clients.  Both mechanisms
   require a trusted relationship between the Front-End and Back-End --
   the delegated credential can be used in place of a certificate
   private key, and the remote key signing case is effectively a signing
   oracle for TLS connections using that certificate.

Section 4.1.1, 4.1.2

The server MUST ignore the extension unless
   TLS 1.3 or a later version is negotiated.  [...]

How do we feel about DTLS?

   The expected_cert_verify_algorithm field MUST be of a type advertised
   by the client in the SignatureSchemeList and is considered invalid
   otherwise.  [...]

This is quoted from 4.1.1.) In 4.1.2, the analogous text also
requires the 'algorithm' to be advertised in "signature_algorithms"
(in CertificateRequest in that case).  I think that the same
condition on "signature_algorithms" (in ClientHello) also applies
here (and I proposed that change in my PR).

Section 4.2

The client MUST NOT accept a delegated credential unless
   the server's end-entity certificate satisfies the following criteria:

   *  It has the DelegationUsage extension.

   *  It has the digitalSignature KeyUsage (see the KeyUsage extension
  defined in [RFC5280]).

Sho

Re: [TLS] TLS1.3 Ticket Usage Across Versions

[Benjamin Kaduk]

On Fri, Nov 12, 2021 at 04:23:12PM -0800, Steven Collison wrote:
> Hello,
> 
> While testing a TLS1.3 client implementation, I found an unexpected
> behavior. Specific sequence:
> 1. Client negotiates TLS1.3 with Server.
> 2. Server sends NST with a valid ticket.
> 3. Client reconnects to the same Server. The ClientHello contains both the
> `session_ticket` and `pre_shared_key` extensions. The value of the
> `psk_identity` is equal to the value of the `session_ticket`.
> 
> Is it ever valid for a client to populate both extensions with the same
> ticket value? Even if the client reconnects and lands on a different server
> node that only supports TLS1.2, resumption should fail because the protocol
> version should be included as part of the session state. The
> `session_ticket`  extension data in this example is at least wasted data.
> 
> I did not see anything in the spec(neither 8446 2.2 nor 4.6.1) that
> explicitly disallows this. 2.2 contains “Both mechanisms are obsoleted in
> TLS 1.3.” when referring to `session_ticket` and `session_id` resumption,
> but that may not be clear enough.

"Obsoleted in TLS 1.3" is not a very good argument, since we do allow
sending a ClientHello that will be valid for both TLS 1.2 and TLS 1.3.

I think the relevant requirement here (phrased as binding on the server,
but by extension on what the client should expect) is in
https://datatracker.ietf.org/doc/html/rfc8446#section-4.6.1:

   Any ticket MUST only be resumed with a cipher suite that has the same
   KDF hash algorithm as that used to establish the original connection.

There is some history to that part of the text that used to have a longer
list of requirements (e.g., including matching SNI), but it got trimmed
down over time to just this one, needed for safety of the key schedule.

There is a certain reading that treats "KDF hash algorithm" as including the
KDF construction itself, i.e., limiting the protocol version used, though
there can be cases where the TLS 1.2 PRF uses the same hash algorithm used
for a TLS 1.3 HKDF, so it's not an ironclad argument.

Contrast this to the requirements for using early data, 
https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.10:

   In order to accept early data, the server MUST have accepted a PSK
   cipher suite and selected the first key offered in the client's
   "pre_shared_key" extension.  In addition, it MUST verify that the
   following values are the same as those associated with the
   selected PSK:

   -  The TLS version number

   -  The selected cipher suite

   -  The selected ALPN [RFC7301] protocol, if any

For early data, the TLS version is indeed specifically called out.


My recollection of the discussions leading up to
https://github.com/tlswg/tls13-spec/commit/fc685853ce52a320fa99cd46e48cf7f8954ff663
are that the TLS 1.3 session ticket was to be tied to the protocol version, but
the text doesn't really seem to support that.

So, in summary, I don't think it's ever actually valid to populate both, but
I can't find solid evidence in RFC 8446 to support that claim in the amount
of time I allocated to look for it just now.

Thanks for asking; it's interesting to hear about such an unusual client 
implementation!

-Ben

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

[TLS] Fwd: Last Call: (Channel Bindings for TLS 1.3) to Proposed Standard

[Benjamin Kaduk]

This draft got some previous discussion on the WG list, but it's worth
having people take another look at it during last call.
In particular, note that it updates RFC 8446.

-Ben

On Fri, Oct 01, 2021 at 11:20:35AM -0700, The IESG wrote:
> 
> The IESG has received a request from the Common Authentication Technology
> Next Generation WG (kitten) to consider the following document: - 'Channel
> Bindings for TLS 1.3'
>as Proposed
>   Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> last-c...@ietf.org mailing lists by 2021-10-15. Exceptionally, comments may
> be sent to i...@ietf.org instead. In either case, please retain the beginning
> of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>This document defines a channel binding type, tls-exporter, that is
>compatible with TLS 1.3 in accordance with RFC 5056, On Channel
>Binding.  Furthermore it updates the "default" channel binding to the
>new binding for versions of TLS greater than 1.2.  This document
>updates RFC5801, RFC5802, RFC5929, and RFC8446.
> 
> 
> 
> 
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-kitten-tls-channel-bindings-for-tls13/
> 
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> 
> 
> 

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

[TLS] AD review of draft-ietf-tls-external-psk-guidance-02

[Benjamin Kaduk]

Hi all,

In general the content here is good, though there's a few things in
sections 4 and 4.1 that I'm not entirely sure about, and we might stand
to be a bit more clear about to what extent TLS pre 1.3 is in scope (we
do talk about it in some places, but the declared scope is only (D)TLS
1.3 plus cTLS (which is a 1.3 variant).

I made a PR with some basically editorial suggestions:
https://github.com/tlswg/external-psk-design-team/pull/68

It seems like we might want to have a sentence or two in the
introduction or terminology section defining what we mean by "external
PSK" (e.g., "a symmetric secret key provided to the TLS library as an
external input").  I think the first mention of "provisioned
out-of-band" is currently not until §6...

Should we have a note that when we write "TLS 1.3" it applies to DTLS
and cTLS as well?

Section 1

The abstract notes that this document "lists the privacy and security
properties that are not provided by TLS when external PSKs are used",
but I don't see much analogous to that in the Introduction.  (The
overlap between Abstract and Introduction is a bit higher than I prefer,
but I don't have any suggested improvements.)


Section 4

   External PSK authentication in TLS allows endpoints to authenticate
   connections using previously established keys.  These keys do not
   provide protection of endpoint identities (see Section 5), nor do

We might want to disambiguate between "authentication of endpoint
identities" and "confidentiality protection for endpoint identities",
since just "protection" could read as either one.  (Also applies to the
following sentence.)

   they provide non-repudiation (one endpoint in a connection can deny
   the conversation).  Protection of endpoint identities and protection
   against an endpoint denying the conversation are possible when a
   fresh TLS handshake is performed.

I don't understand the last sentence -- is this a "fresh TLS handshake"
using the same external PSK that we just said doesn't provide these
things?  Are we equating "fresh handshake" with "uses certificates"?

Section 4.1

   2.  If PSK with DH is used, then compromise of a group member that
   actively completes connections with other group members can read
   (and modify) traffic.

I can't parse this sentence: "If , then compromise of " needs
another clause, like "allows the attacker to ", but currently the
sentence parses with  basically consuming the rest of the sentence.

(Also, does "actively complete" mean to receive, initiate, or both?)

   4.  If a group member is compromised, then the attacker can perform
   all of the above attacks.

I'm not sure I understand how this item adds value, since (2) and (3)
explicitly assume "compromise of a group member" and for the case of (1)
compromising a group member naturally satisfies "any group member
can...".

   Additionally, a malicious non-member can reroute handshakes between
   honest group members to connect them in unintended ways, as described
   below.  Note that this class of attack is not possible if each member
   uses the SNI extension [RFC6066] and terminates the connection on
   mismatch.  See [Selfie] for details.

SNI only authenticates the server identity; it seems that if (e.g.) A
and B both initiate connections to C at the same time, the attacker can
make C think that A and B's connections/identities are swapped.  (I
don't remember if [Selfie] directly touches on this attack or not.)

   This attack violates the peer authentication property, and if "C"
   supports a weaker set of cipher suites than "B", this attack also
   violates the downgrade protection property.  [...]

I think we might want to say a little more about how this violdates the
downgrade protection property (or "fails to provide downgrade
protection", since violating a property is a somewhat unusual phrasing).
Most of the instances of the word "downgrade" in RFC 8446 rever to (TLS)
version downgrade, with essentially only the definition of "downgrade
protection" in Appendix E.1 mentioning arbitrary "cryptographic
parameters" that should be the same on both peers as in the absence of
an attack.  But in this setup we have three entities involved, and it's
not clear to which pair we should apply the test -- if A was intending
to talk to C, it would get the same parameters it actually did.  And the
attacker doesn't really affect the negotiation per se -- it can't force
a weaker cipher just because C has it enabled.  A has to offer it, and
it has to be the one that C actually picks.  So the negotiated
ciphersuite would only be different if B and C have different
most-preferred ciphers from A's list, which is perhaps a bit harder to
achieve in practice than just "C supports weaker ciphers".

Section 6.1

   *  Some secrets may be baked into or hardware or software device
  components.  Moreover, when this is done at manufacturing time,
  secrets may be printed on labels or included in a Bill of
  Materials for

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

[Benjamin Kaduk]

On Tue, Aug 17, 2021 at 07:25:33PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> I see absolutely nothing wrong with using FFDH(E) and ECDH, as long as at 
> least one of the keys is ephemeral. There is no need to “warn away”, IMHO. 

That's an interesting position to take.  Let me see if I understand it 
correctly.
(I will just write "DH" even though I mean (EC)DH.)

Static-static DH results in re-generating the same derived key on multiple 
protocol
instantiations, which is in some sense reusing a single key for multiple things 
and
thus disrecommended.  Though, in TLS, we have the Randoms that go into the key 
schedule,
so the actual traffic/Finished/etc. keys will diverge even for the 
static-static case.
However, it's hard to do formal analysis when the same secret is used across 
many
protocol instantiations spread out over time, and one has to ensure that the 
Randoms
actually are non-repeating in order for this to be a reliable scheme.  So 
there's plenty
of risk here and reasons to stay away.

Ephemeral-static DH makes a new derived key for each protocol instantiation and
simplifies the analysis (though subject to similar caveats as above about 
actually
using a unique ephemeral value each time).  It's clearly an improvement over 
static-static,
but anyone armed with a protocol transcript who discovers the secret part of 
the static
DH value can recover the derived key and deprotect the application data.  
Forward secrecy
is not obtained until the "static" private value is discarded, leaving risk of 
loss
of confidentiality due to endpoint compromise.

Ephemeral-ephemeral DH also makes a new derived key for each protocol 
instantiation, but
also allows the private DH values to be discarded "immediately", before any 
significant
application data is protected using key material stemming from the derived key. 
 This provides
the strongest kind of forward secrecy (provided that endpoints actually discard 
the private
ephemeral values), and is again a step up from the ephemeral-static case.

In light of the above, it seems that your concerns are more focused on "key 
reuse" than
forward secrecy.  Is that correct?
I have heard a lot of people saying that forward secrecy is important to them, 
so it's
not clear that your stance is the consensus position.

Thanks,

Ben

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

[TLS] FYI: discussion on TLS 1.2 SignatureAlgorithm IANA allocation

[Benjamin Kaduk]

Hi all,

I recently did an RFC 5742 conflict review of a document that is
allocating new cipher suites for TLS 1.2 and also needs new signature
algorithms.  The document currently requests two allocations from the old TLS
1.2 SignatureAlgorithm registry that TLS 1.3 replaced with the two-octet
SignatureScheme registry.  (Actually, the registrations have been live for
2.5 years but the document is just getting ready for publication as an RFC
now.)

I tried to summarize the history and WG intent at the time of RFCs
8446/8447 in a note to tls-reg-review
(https://mailarchive.ietf.org/arch/msg/tls-reg-review/1RJOKg9Cnt1PHS-iOC5sOOt5aeE/)
and wanted to send a heads-up here in case I'm misrepresenting history
and/or WG intent.

Please send any follow-ups to me directly; I will collate and report back
if it turns out that I did get things wrong.

-Ben

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

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

[Benjamin Kaduk]

On Fri, Aug 06, 2021 at 03:03:47PM -0400, Viktor Dukhovni wrote:
> 
> That said, I've given up fighting potentially counter-productive "raising the 
> floor"
> rather than "the celing" on all fronts, and now try to focus on just the most 
> important
> cases.  Thus have accepted the fact that sadly no anon (EC)DH ciphers are 
> available with
> TLS 1.3.

Well, yes, because TLS 1.3 ciphers only indicate the hash function and AEAD.

-Ben

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

Re: [TLS] [Technical Errata Reported] RFC5246 (6572)

[Benjamin Kaduk]

I agree that this isn't an appropriate change for an erratum.

Even with a new RFC updating RFC 5246, we'd still need to have some
discussion about a transition plan, at which point just relying
on the guidance in BCP 195 becomes more and more attractive.

-Ben

On Wed, May 05, 2021 at 04:00:00PM -0700, Eric Rescorla wrote:
> I'm not sure precisely what attacks you are referring to here. In
> particular, I'm not aware of any known security issues with HMAC-SHA1. With
> that said, I agree that we wouldn't choose AES_128_CBC_SHA as a default
> now, but this isn't usually the kind of thing we would usually use an
> erratum for. Rather, this would be appropriate for a new RFC updating 5246.
> 
> -Ekr
> 
> 
> On Wed, May 5, 2021 at 3:21 AM RFC Errata System 
> wrote:
> 
> > The following errata report has been submitted for RFC5246,
> > "The Transport Layer Security (TLS) Protocol Version 1.2".
> >
> > --
> > You may review the report below and at:
> > https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid6572__;!!GjvTz_vk!FfdA-HJa47sbeeDEDwh3TNDNxVmLXLJdZQ-bzn4yM_KdLFt6kEcEiWduzMMlqw$
> >  
> >
> > --
> > Type: Technical
> > Reported by: Johannes Görlich 
> >
> > Section: 9
> >
> > Original Text
> > -
> > In the absence of an application profile standard specifying otherwise, a
> > TLS-compliant application MUST implement the cipher suite
> > TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the definition).
> >
> > Corrected Text
> > --
> > In the absence of an application profile standard specifying otherwise, a
> > TLS-compliant application MUST implement the cipher suite
> > TLS_RSA_WITH_AES_128_GCM_SHA256 (see Appendix A.5 for the definition).
> >
> > Notes
> > -
> > A must-be-implement cipher suite should not relay on a bulk encryption
> > algorithm which is vulnerable to plain-text attacks or on a secure hash
> > algorithm which has been proven to be insecure.
> >
> > 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.
> >
> > --
> > RFC5246 (draft-ietf-tls-rfc4346-bis-10)
> > --
> > Title   : The Transport Layer Security (TLS) Protocol Version
> > 1.2
> > Publication Date: August 2008
> > Author(s)   : T. Dierks, E. Rescorla
> > Category: PROPOSED STANDARD
> > Source  : Transport Layer Security
> > Area: Security
> > Stream  : IETF
> > Verifying Party : IESG
> >

> ___
> TLS mailing list
> TLS@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!FfdA-HJa47sbeeDEDwh3TNDNxVmLXLJdZQ-bzn4yM_KdLFt6kEcEiWd4LHbbkQ$
>  

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

Re: [TLS] SNI as authorization token?

[Benjamin Kaduk]

Thanks Martin, Rob.

Funnily enough, my draft ballot position (even before your note) contains:

I'm extremely reluctant to suggest using SNI in this manner (as an
impromptu authorization bearer token, akin to port knocking).

Since you got your replies in while I was taking an interrupt for something
else, I can relay the tentative suggestion to remove the whole appendix as well.

-Ben

On Wed, May 05, 2021 at 12:57:03PM +1000, Martin Thomson wrote:
> I agree with Rob here.  Removing the appendix would be best.  It's true that 
> some servers have special names, but that is for operational reasons.  
> Pretending that something you put on the wire in the clear is a security 
> mechanism would be dishonest.
> 
> This reminds me of port knocking.  It's not an effective defense against a 
> motivated attacker, but people deploy it anyway.  If the IETF were to 
> recommend that, then it would have to come with stronger safeguards than 
> "maybe ECH will make this secure one day".
> 
> On Wed, May 5, 2021, at 09:30, Rob Sayre wrote:
> > On Tue, May 4, 2021 at 4:20 PM Benjamin Kaduk 
> >  wrote:
> > > Hi all,
> > > 
> > > I'm reviewing draft-ietf-dprive-xfr-over-tls for this week's IESG 
> > > telechat, and
> > > in 
> > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-dprive-xfr-over-tls-11*appendix-A.3__;Iw!!GjvTz_vk!Ay4HBe8M-L8oJtejnDhdK4oRwRyfeHdsZ7fbNfWtTZR-Jzifm-McY2xk_4gN1g$
> > >  
> > > it seems to suggest that a TLS server might only choose to allow 
> > > connections that
> > > include a specific (secret-ish) SNI value.  Given that the "as above" 
> > > listed "con"
> > > seems to indicate that there are no relevant implementations of this 
> > > functionality,
> > > I plan to push back on its inclusion in the document; a PSK mode (with 
> > > cert,
> > > per RFC 8773) would seem to be universally superior.
> > > 
> > > Am I correct to do so?  Do we know of any cases where the SNI value is 
> > > being
> > > (ab)used as an authorization token in this manner?
> > 
> > It certainly happens with subdomains. I'd recommend removing that 
> > entire appendix, though. It seems like generic TLS / DoS advice that 
> > doesn't really belong in the document.
> > 
> > thanks,
> > Rob
> >  
> > ___
> > TLS mailing list
> > TLS@ietf.org <mailto:TLS%40ietf.org>
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!Ay4HBe8M-L8oJtejnDhdK4oRwRyfeHdsZ7fbNfWtTZR-Jzifm-McY2wG6e-TtQ$
> >  
> > 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!Ay4HBe8M-L8oJtejnDhdK4oRwRyfeHdsZ7fbNfWtTZR-Jzifm-McY2wG6e-TtQ$
>  

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

[TLS] SNI as authorization token?

[Benjamin Kaduk]

Hi all,

I'm reviewing draft-ietf-dprive-xfr-over-tls for this week's IESG telechat, and
in 
https://datatracker.ietf.org/doc/html/draft-ietf-dprive-xfr-over-tls-11#appendix-A.3
it seems to suggest that a TLS server might only choose to allow connections 
that
include a specific (secret-ish) SNI value.  Given that the "as above" listed 
"con"
seems to indicate that there are no relevant implementations of this 
functionality,
I plan to push back on its inclusion in the document; a PSK mode (with cert,
per RFC 8773) would seem to be universally superior.

Am I correct to do so?  Do we know of any cases where the SNI value is being
(ab)used as an authorization token in this manner?

Thanks,

Ben

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

Re: [TLS] Éric Vyncke's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)

[Benjamin Kaduk]

Hi Éric,

Trimming heavily, as several other responses have landed already...

On Mon, Apr 19, 2021 at 12:47:51AM -0700, Éric Vyncke via Datatracker wrote:
> 
> 
> --
> COMMENT:
> --
> 
> -- Section 3 --
> While I am not a DTLS expert, I find this section quite difficult to 
> understand
> the reasoning behind the specification as little explanations are given about,
> e.g, what is the motivation of "A zero-length value indicates that the server
> will send with the client's CID but does not wish the client to include a 
> CID."

We had a lot of discussion in the WG about zero-length CIDs and the various
edge cases that can arise.  (You might imagine, for example, wanting to use
the new record format and get content-type confidentiality even when a CID
is not needed for routing messages.)  We ended up concluding that it's
simpler and safer to do what's described now -- no CID means the RFC 6347
record format.  But the discussion in the document may not have captured
the full extent of the WG discussion, so we can take a look at whether
there is more to be said.

The short answer is that this is a typical mechanism where each part tells
the other how to contact them, but in order to confirm the negotiation to
use the feature, we need a signal for "I don't need a CID but I support
CIDs", and the zero-length field in the handshake packets plays that role
quite naturally.

-Ben

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

Re: [TLS] Secdir telechat review of draft-ietf-tls-exported-authenticator-14

[Benjamin Kaduk]

Hi Yaron,

Thanks for the (multiple!) reviews.

My understanding is that the intention is not to allow "server_name" in all
CertificateRequests but only specifically in the ClientCertificateRequest
case.  I think it can be helpful to notate that with a "CR" in the "TLS
1.3" column of the registry but we would need some further clarification as
to what that notation actually means.  I left some suggestions for how to
do that in my ballot position, but to summarize: a "comment" column in the
registry would be great for this, and failing that a note in the IANA
Considerations of this document to clarify what is and is not being
registered would probably work as well.

Thanks again for highlighting this point,

Ben

On Fri, Apr 02, 2021 at 09:05:38AM -0700, Yaron Sheffer via Datatracker wrote:
> Reviewer: Yaron Sheffer
> Review result: Has Issues
> 
> After a bit of back and forth over my *two* previous SecDir requests, I'm
> afraid that my original comment has not yet been fully addressed. The IANA
> considerations section (Sec. 8.1) adds server_name as a possible extension for
> CertificateRequest. This would be a non-backward compatible change to TLS.
> 
> IMO what we needed to do is both to clarify the allowed extensions for what
> Nick called "the CR-like structure" (almost done in Sec. 4, though the last
> sentence should by changed to include CertificateRequest) and undo the change
> to the TLS ExtensionType registry (not done, would require to remove Sec. 
> 8.1).
> 
> * Nit: this sentence is repeated almost verbatim in Sec. 4 and Sec. 5, and in
> both cases is mangled.
> 
> Old:
> 
> The application layer protocol used to send the authenticator request SHOULD
> use a secure with equivalent security to TLS, such as QUIC [QUIC-TLS], as its
> as its underlying transport to keep the request confidential.
> 
> New:
> 
> The application layer protocol used to send the authenticator request SHOULD
> use a secure *channel* with equivalent security to TLS, such as QUIC
> [QUIC-TLS], as its ~~as its~~ underlying transport to keep the request
> confidential.
> 
> 

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

[TLS] Benjamin Kaduk's Yes on draft-ietf-tls-exported-authenticator-14: (with COMMENT)

[Benjamin Kaduk via Datatracker]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-tls-exported-authenticator-14: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/



--
COMMENT:
--

I've made some (mostl) editorial suggestions in a github PR:
https://github.com/tlswg/tls-exported-authenticator/pull/73

Despite the overall YES ballot, I do have some substantive comments that
may be worth some further consideration.

Do we want to give any insight or examples into how an application might
choose to use the certificate_request_context?

Thanks to Yaron Sheffer for the multiple secdir reviews.  My
understanding is that the intent of this document is to only allow
"server_name" to appear in the ClientCertificateRequest structure that
otherwise uses the "CR" notation in the TLS 1.3 column of the TLS
ExtensionType Values registry, but not to allow for "server_name" in
authenticator CertificateRequests or handshake CertificateRequests.
Assuming that's correct, the easiest way to indicate that would be if
there was a "Comment" column in the registry that could say "only used
in ClientCertificateRequest certificate requests and no other
certificate requests", but there is not such a column in the registry.
I think it could also work to be much more clear in the IANA
considerations of this document as to why the "CR" is being added and
what restrictions there are on its use, even if that's not quite as
clean of a solution.

Section 1

   multiple identities -  Endpoints that are authoritative for multiple
  identities - but do not have a single certificate that includes
  all of the identities - can authenticate additional identities
  over a single connection.

IIUC this is only new functionality for server endpoints, since client
endpoints can use different certificates for subsequent post-handshake
authentication events.

   TLS (or DTLS) version 1.2 [RFC5246] [RFC6347]. or later are REQUIRED
   to implement the mechanisms described in this document.

Please clarify whether this is a minimum TLS version required for using
EAs, or that this is a binding requirement on implementations of the
named protocol versions.  (If the latter is intended we may have some
discussions about an Updates: tag...)

Section 5.1

Using an exporter value as the handshake context means that any client
authentication from the initial handshake is not cryptographically
digested into the exporter value.  In light of what we ran into with
EAP-TLS1.3, do we want to revisit whether we're still happy with that?
We should in practice still benefit from the implicit confirmation that
anything the server participates in after receiving the Client Finished
means the server properly validated it and did not abort the handshake,
but it's a bit awkward, especially since the RFC 8446 post-handshake
authentication does digest the entire initial handshake transcript.
Would we feel any safer if an exporter variant was available that
digested the entire initial handshake transcript and we could use that?

Section 5.2.1

   Certificates chosen in the Certificate message MUST conform to the
   requirements of a Certificate message in the negotiated version of
   TLS.  In particular, the certificate chain MUST be valid for the
   signature algorithms indicated by the peer in the
   "signature_algorithms" and "signature_algorithms_cert" extension, as
   described in Section 4.2.3 of [TLS13] for TLS 1.3 or the
   "signature_algorithms" extension from Sections 7.4.2 and 7.4.6 of
   [RFC5246] for TLS 1.2.

This seems awkward.  Do "the requirements of a Certificate message in
the negotiated version of TLS" include the actual message structure?
Because the rest of the document suggests that we always use the TLS 1.3
Certificate, but this line would set us up for using a TLS 1.2
Certificate.

Also, per §1.3 of RFC 8446, "signature_algorithms_cert" also applies to
TLS 1.2, so the last sentence seems incorrect or at least incomplete.

Section 5.2.1

   Otherwise, the Certificate message MUST contain only extensions
   present in the TLS handshake.  Unrecognized extensions in the
   authenticator request MUST be ignored.

At least the first sentence seems redundant with the previous section
(but I did not propose removing this in my editorial PR).  The second
sentence arguably follows

Re: [TLS] Martin Duke's Discuss on draft-ietf-tls-dtls13-41: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

Hi Martin,

Thanks for starting the separate thread to cover the transport topics.

I'll trim heavily to call out one topic that might benefit from some
attention from the working group...

On Wed, Mar 24, 2021 at 02:42:00PM -0700, Martin Duke via Datatracker wrote:
> 
> Finally, a really weird one. Reading this document and references to 
> connection
> ID prompted to me to think how QUIC-LB could apply to DTLS. The result is 
> here:
> https://github.com/quicwg/load-balancers/pull/106/files. Please note the 
> rather
> unfortunate third-to-last paragraph. I'm happy to take the answer that this 
> use
> case doesn't matter, since I made it up today. But if it does, it would be 
> very
> helpful if (1) DTLS 1.3 clients MUST include a connection_id extension in 
> their
> ClientHello, even if zero length, and/or (2) this draft updated 4.1.4 of 8446
> to allow the server to include connection_id in HelloRetryRequest even if the
> client didn't offer it. Thoughts?

(To over-summarize: the proposal to make connection_id mandatory in DTLS
1.3 ClientHello is an attempt to support the case where a single load
balancer fronts for both DTLS 1.3 and QUIC servers and connection IDs are
required.  If the client does not send the extension in this case the
DTLS server is toast and will not get its packets reliably.)

-Ben

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

Re: [TLS] [Editorial Errata Reported] RFC8996 (6492)

[Benjamin Kaduk]

Agreed on all counts.

RFC Editor, this phrase appears twice in Section 1.1 -- do you know if the
inline errata tooling will do something useful with the Original/Corrected
text as currently shown, or should I extract a larger snippet so that both
instances can be done together?

Thanks,

Ben

On Tue, Mar 23, 2021 at 03:03:14PM -0700, RFC Errata System wrote:
> The following errata report has been submitted for RFC8996,
> "Deprecating TLS 1.0 and TLS 1.1".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6492
> 
> --
> Type: Editorial
> Reported by: Martin Thomson 
> 
> Section: 1.1
> 
> Original Text
> -
> ServerHello.Random
> 
> Corrected Text
> --
> ServerHello.random 
> 
> Notes
> -
> Very pedantic, but RFC 8446 uses all lowercase for "random" to match the 
> grammar.
> 
> 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. 
> 
> --
> RFC8996 (draft-ietf-tls-oldversions-deprecate-12)
> --
> Title   : Deprecating TLS 1.0 and TLS 1.1
> Publication Date: March 2021
> Author(s)   : K. Moriarty, S. Farrell
> Category: BEST CURRENT PRACTICE
> Source  : Transport Layer Security
> Area: Security
> Stream  : IETF
> Verifying Party : IESG

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

Re: [TLS] Regarding draft-bartle-tls-deprecate-ffdhe

[Benjamin Kaduk]

On Mon, Mar 08, 2021 at 10:52:15AM -0800, Carrick Bartle wrote:
> If the draft to deprecate 1.0 and 1.1 becomes an RFC while this is still a 
> draft, I'll remove all mention of 1.0/1.1.

I expect it to become an RFC this week.

-Ben

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

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

[Benjamin Kaduk]

Hi Peter,

Just to confirm: the scenario you're using to contrast to the one described
by Viktor (and Nico) is a scenarios in which the certificates expire at "never"
(1231235959Z)?

I think that at least some people are contrasting against something other
than that...

Thanks,

Ben

On Mon, Mar 08, 2021 at 03:21:22AM +, Peter Gutmann wrote:
> Viktor Dukhovni  writes:
> 
> >But if the signal is not ignored, and proper automation is applied,
> >reliability actually improves.
> 
> No, it drops.  You're going from a situation where you've eliminated any
> chances of outages due to expired certs to one where you get to play Russian
> roulette every single day: Will the cert renewal work, or will it fail for
> some reason?  Let's spin the cylinder and see if this is the day our grid goes
> down.
> 
> Even if you somehow create a 100% successful magical process for replacing
> certs that never ever fails, you're now introduced another possible failure
> situation, with certs changing constantly there's a chance that something that
> relies on them can't handle a new cert, for example because an issuing CA has
> renewed as well or something similar.
> 
> It's just building in more and more opportunities for failure from a mechanism
> that's supposed to be making your infrastructure more robust, not less.
> 
> Peter.
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!GaaCbhUsGvSdgqi6crkwhODrap4fYzdX6pgIOq4zyhG9nX88r3GTRHuFOsw1ew$
>  

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

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

[Benjamin Kaduk]

On Sun, Mar 07, 2021 at 12:15:24PM +, Graham Bartlett wrote:
> 
> I would imagine that the implementation would pull the session down once
> the certificate expires, so the session only lasts for the lifetime of the
> certificate.

Many people expect this, but I don't think there's universal agreement
that it's the right behavior.  The divide between authentication and
authorization that (IIRC) Viktor called out is relevant here -- the
initial key exchange and, to large extent, authentication, do not suddenly
become invalid upon credential expiry, but any authorization derived from
the credential might.  So it seems that whether the session should terminate
at the certificate expiry time is rather dependent on what the session is
being used for.

-Ben

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

Re: [TLS] Genart last call review of draft-ietf-tls-dtls13-41

[Benjamin Kaduk]

Hi Dan,

On Tue, Feb 16, 2021 at 12:41:53AM -0800, Dan Romascanu via Datatracker wrote:
> Reviewer: Dan Romascanu
> Review result: Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-tls-dtls13-51
> Reviewer: Dan Romascanu
> Review Date: 2021-02-16
> IETF LC End Date: 2021-02-22
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: Ready
> 
> This document updates RFC6347 (DTLS 1.2) with version 1.3 of the protocol. 
> It's
> a clear, well structured and mature document, justifying the time and number 
> of
> successive iterations spent in writing it.
> 
> Major issues:
> 
> Minor issues:
> 
> Nits/editorial comments:
> 
> Is really [RFC6347] which this document OBSOLETEs only an Informative 
> Reference?

Thanks for the review!

I don't really understand this comment, though -- the only other choice is
to be a normative reference, but we couldn't make a normative reference to
an obsolete document.  Was there something in particular that you thought
required 6437 to be a normative reference?

Thanks,

Ben

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

Re: [TLS] [Emu] Protected Result Indicators in EAP-TLS 1.3

[Benjamin Kaduk]

On Wed, Feb 10, 2021 at 10:48:10AM +, John Mattsson wrote:
> With Alan's comments, I think we are down to 3 alternatives:
> 
> (1a). Use close_notify alert as protected success.
>   Use error alerts as protected failure.
> 
>  - Forbid close_notify except as success indication
>  - Mandate Error alert before EAP-Failure
>  - Forbid all use of user_cancelled
> 
> (1b). Use close_notify alert as protected success.
>   Use all other alerts as protected failure.
> 
>   - Forbid close_notify except as success indication
>   - Mandate Error alert or user_cancelled before EAP-Failure
> 
> (2). Use application data as protected success.
>  Use all alerts as protected failure.
> 
> - After sending application data in an EAP-Request the EAP-TLS server 
> MUST send only EAP-Success.
> - Mandate alert (closure, error) before EAP-Failure
> 
> I think it is important to discuss what the ongoing EMU consensus call will 
> mean in practice. Previous discussions was mostly about not sending more 
> handshake messages. Protected result indicators are quite different.
> 
> It would we very good with early feedback from Ben and the TLS WG if they see 
> problems with any of the alternatives.

On first look it seems like all of those will be able to achieve the
required properties.  In some sense it is "probably" going to be "easier"
for an application using TLS to use TLS application data (as opposed to
alerts) to affect its behavior, though I believe that TLS implementations
generally do provide the needed information about received alerts and
flexibility in what alert to send that's needed for the (1) variants.

Another potential factor that I'm not (currently) equipped to evaluate is
the reusability of the machinery defined by EAP-TLS for use by other EAP
mechanisms.  E.g., if we say that for EAP-TLS any application data is a
protected success, would that be in conflict with any scenarios for the EAP
mechanisms that do have to send some data on the TLS application data
stream?

I'd be happy to hear some more voices from the TLS WG chiming in to
corroborate (or contradict) my conclusions in the first paragraph.

Thanks,

Ben

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

Re: [TLS] EXTERNAL: TLS 1.3 Authentication and Integrity only Cipher Suites

[Benjamin Kaduk]

On Thu, Feb 11, 2021 at 12:40:51AM -0200, Viktor Dukhovni wrote:
> 
> There is merit in keeping the combinatorial complexity of TLS 1.3
> as small as possible, reducing implementation attack surface, ...
> 
> The key question, that is difficult to answer is whether the right
> balance is adequately accomplished with "N" in the recommended column,
> with most implementations then either not supporting said ciphersuites
> at all, or disabling them by default.  If so, perhaps some specialised
> implementations could use them appropriately.  On the other hand the
> "specialised" applications might get used outside their originally
> intended use-cases, in ways the designers never anticipated.
> 
> Do we leave the choice to use TLS wisely to the developers and users,
> or we judge that misuse is inevitable, and the use-case not sufficiently
> compelling?  I am somewhat inclined to do the latter.  Despite the fact
> that'd I'd otherwise be inclined to argue for anonDH ciphers, which have
> reasonable applications in unauthenticated opportunistic TLS, where any
> presented certificates are just ignored bloat that increase the attack
> surface.  I would have liked to see support for these retained in TLS 1.3,
> but accept their omission as a legitimate tradeoff.  If NULL ciphers are
> added (which IMHO are the greater risk), then perhaps I'd have a good
> case to make to have anonDH/anonECDH ciphers re-introduced...

The WG has delegated this decision to the Designated Experts that serve
for the relevant IANA registry.  In point of fact, the experts have already
approved ciphersuite codepoints for these ciphers (a couple years ago, IIRC),
so in some sense the decisions (or "a decision"?) has already been made.

The WG could, of course, decide to provide additional input to the Experts
in the form of a new RFC (or a number of other ways), including
clarifying how the requirement in Appendix D.5 that "ciphers with a strength
less than 112 bits MUST NOT be offered or negotiated for any version of TLS for
any reason" is to be interpreted, whether NULL encryption is compatible with
an AEAD requirement, etc.

On the other hand, I suspect that attempts to make the registration policy
too strict would just lead to codepoint squatting, a phenomenon with which
we have some real-world experience...

-Ben

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

Re: [TLS] AD Evaluation of draft-ietf-tls-dtls13-39

[Benjamin Kaduk]

On Sun, Feb 07, 2021 at 12:45:01PM -0800, Eric Rescorla wrote:
> I have posted -41, which I believe to be ready for IETF LC

I concur, and thanks for the quick updates.

(It looks like I goofed and caused a duplicate RFC 8446 reference, but we
can tell the genart reviewer it's fixed in the editor's copy already.)

Sending it over to the secretariat now...

-Ben

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

Re: [TLS] AD Evaluation of draft-ietf-tls-dtls13-39

[Benjamin Kaduk]

Hi Ekr,

Thanks for all the updates, and sorry to have dropped the ball over the
holidays.

The changes in the -40 are basically all good, and I filed several PRs to
cover a few nits and places where you asked for suggested text.  (I see you
merged most of them already; thanks!)  For everybody not getting
notifications for the githb repo, those are:

https://github.com/tlswg/dtls13-spec/pull/208 (general nits)
https://github.com/tlswg/dtls13-spec/pull/209 (implementation pitfalls)
https://github.com/tlswg/dtls13-spec/pull/210 (anti-replay window per epoch)
https://github.com/tlswg/dtls13-spec/pull/211 (implicit ACK)
https://github.com/tlswg/dtls13-spec/pull/212 (more security considerations)

The only other comment I had on the -40 that I didn't make a PR for is that
(now that we have the automation working to generate appendixes for the
procotol-description language) we don't actually show the new value for ACK
as a ContentType anywhere!  It seems like we'd have to stick that in Figure
2 if we put it anywhere, though that's admittedly a bit disjointed from
where we actually start talking about the message in question.

Some additional notes inline (I think there's a couple that introduce the
possibility of new text that is not currently associated with a github
issue or PR).

On Mon, Dec 07, 2020 at 07:15:13AM -0800, Eric Rescorla wrote:
> Ben,
> 
> Thanks for your review.
> 
> 
> > I made a pull request with editorial/nit-level stuff at
> > https://github.com/tlswg/dtls13-spec/pull/160 (though some editorial
> > issues remain mentioned here where there is a lot of flexibility in how
> > to resolve them).
> 
> I will take a look at these.
> 
> 
> > I think there are probably some DTLS-specific "implementation pitfalls"
> > that might merit a section akin to RFC 8446's Appendix C.3.
> >
> > I also mention in the per-section comments a few places where we should
> > say a bit more about how we diverge from RFC 8446, and a few places
> > where being more explicit about separate read and write epochs would be
> > helpful.
> >
> > Section 1
> >
> >1.2 (see Appendix D of [TLS13] for details).  While backwards
> >compatibility with DTLS 1.0 is possible the use of DTLS 1.0 is not
> >recommended as explained in Section 3.1.2 of RFC 7525 [RFC7525].
> >
> > I guess we might want to reference draft-ietf-tls-oldversions-deprecate
> > by the time we hit the RFC Editor's queue.
> 
> https://github.com/tlswg/dtls13-spec/pull/163
> 
> 
> > Section 2
> >
> >-  connection: A transport-layer connection between two endpoints.
> >
> > Can there even be a datagram "connection"?
> >
> > Regardless, we should define "association" since we use that as well.
> >
> >-  handshake: An initial negotiation between client and server that
> >   establishes the parameters of their transactions.
> >
> > This is the only place in the document where we use the word
> > "transaction", which makes me suspect that it is not the best word
> > choice.
> >
> >-  session: An association between a client and a server resulting
> >   from a handshake.
> >
> > This seems technically true, but could be confusing if we want to have
> > an analogy DTLS Session:TLS Session::DTLS Association:TLS Connection.
> > (Per the previous comments, I am not 100% sure that we are trying to
> > have that anaolgy, though.)
> 
> Sure. I think the original intent was to be as you say, but things may
> have gotten muddled.
> 
> https://github.com/tlswg/dtls13-spec/pull/164
> 
> 
> 
> > Section 3.4
> >
> >DTLS optionally supports record replay detection.  The technique used
> >is the same as in IPsec AH/ESP, by maintaining a bitmap window of
> >
> > Do we want a reference for the IPsec usage?  (We do reference
> > https://tools.ietf.org/html/rfc4303#section-3.4.3 from §4.5.1 when we
> > talk about the mechanics of the replay window.)
> 
> I don't think it's necessary here.

Agreed.

> 
> >Applications may conceivably detect duplicate packets and accordingly
> >modify their data transmission strategy.
> >
> > The text here doesn't give me a clear impression of whether the
> > application is supposed to use the DTLS sequence numbers for this
> > detection, or their own (application layer) information.  (I didn't
> > think that most DTLS implementations exposed an API to give the
> > application the record sequence number.)
> 
> Is there a reason we need to weigh in on this? We don't generally
> take a position on this kind of API issue.

It's not terribly important, so no, we can leave this be.

> 
> > Section 4
> >
> >ProtocolVersion legacy_record_version;
> >
> > We should probably say what value(s) are allowed here, akin to the RFC
> > 8446 "MUST be set to 0x0303 for all records [...] other than an initial
> > ClientHello".
> 
> https://github.com/tlswg/dtls13-spec/pull/165
> 
> >Fixed Bits:  The three high bits of the first byte of the
> >   DTLSCiphertext header are set to 001.
> >
> > Do we want to say 

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

On Mon, Feb 01, 2021 at 07:09:14AM -0500, Alan DeKok wrote:
> On Jan 31, 2021, at 9:16 PM, Benjamin Kaduk  wrote:
> > That's a scenario that I was starting to puzzle over this weekend as well
> > -- with EAP-Success "completely unauthenticated", it would be fairly easy
> > for an on-path attacker to send the EAP-Success the EAP peer was expecting
> > and make the EAP peer think things succeeded even if the server had
> > rejected the client cert.
> 
>   Yes.
> 
> >  Now, a server that has rejected the client cert
> > is hopefully not going to be exporting the keys and continuing to run the
> > next steps of protocol operation, but to some extent it seems that the
> > security of the system as a whole relies on the server operating correctly
> > in this regard.
> 
>   The TLS exporter keys are used for 802.1X / MacSec.  But they're not always 
> used.

Somehow I had convinced myself that the EMSK was only sometimes used, but
MSK was always used.  If MSK is always used, then key confirmation of the
MSK can play the role of handshake (and client authentication)
confirmation, but otherwise I seem to be coming around to your "4.5 round
trips is unavoidable" conclusion.  I'm not sure how clear-cut a distinction
there is between cases that use the keys and those that don't, such that
the last round trip could be shaved off when the exported key is used for
key confirmation...

> > ... it
> > seems like a lot of what is being described as desired here ends up relying
> > on ordering between application data and handshake messages.
> 
>   I think there's no implementation issue here.  The draft should be clearer 
> that there's no guaranteed ordering.

I was going to stick this in a reply to Joe (at
https://mailarchive.ietf.org/arch/browse/emu/), but maybe I can sneak it in
here and save a message in everybody's inbox.

My understanding (based on
https://tools.ietf.org/html/rfc5216#section-2.1.5) is that EAP-TLS
fragments TLS records, or in some cases, groups of records, and the first
fragment includes a four-byte length field for the total message being
fragmented.  Recalling that a given TLS record can only have payload of a
single content type, in the scenario with a 0x00 confirmation message and a
NewSessionTicket, that means one record with inner type application data
and another record with inner type handshake.  If they are both grouped
together to the EAP-TLS fragmentation engine, then I agree that there is no
issue and a proper implementation should be waiting to reassemble the whole
fragmented bundle, including both records, before finalizing processing.
But is it also allowed to fragment the two records separately?  I didn't
see anything that required the entire TLS flight of messages to be
a single fragmentation input, and it's in the case that the 0x00 and
NewSessionTicket are fragmented separately that the ordering becomes
relevant -- if the 0x00 is fragmented first then the peer gets the complete
fragmented message, sees the commitment message, and prepares its
authentication flight in the EAP-Response, and based on the supposed
commitment semantics would then somehow be expected to reject an
EAP-Request with NewSessionTicket as breaking the commitment.  (Assuming it
had a way to tell it was a handshake message at all, that is...)

I'd love to hear what I am missing that makes the above incorrect, and/or
that we have a way to require the NewSessionTicket and commitment message
to be part of the same fragmentation unit.

> > (A lot of my hedging in messages on this thread is because I also don't
> > really understand why the message is there.)
> > I believe I read somewhere that it stemmed from the change in who speaks
> > last in the TLS handshake, but am a bit hazy on how that implies it is
> > needed.
> 
>   I would like clarification on just what that message *means*.  If we want 
> an explicit EAP layer signal that the server saw the client cert and 
> authenticated it, then we MUST NOT send any such signal until after the 
> server has seen the client cert.  And because the EAP-Success is sent all 
> alone, we MUST then have another full round of TLS exchange, before the final 
> EAP-Success.   i.e.
> 
> 
> EAP-TLS Peer  EAP-TLS Server
> 
>  EAP-Request/
>  <  Identity
> EAP-Response/
> Identity (Privacy-Friendly)  >
>  EAP-Request/
> EAP-Type=EAP-TLS
>  <(TLS Start)
> EAP-Response/
&g

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

On Mon, Feb 01, 2021 at 02:52:58PM -0500, Alan DeKok wrote:
> On Feb 1, 2021, at 1:30 PM, Joseph Salowey  wrote:
> > [Joe] This could also address the early export of keys before the peer is 
> > authenticated. RFC 5216 provides a canonical way to create these IDs, but 
> > I'm not sure anyone follows it today
> 
>   FreeRADIUS does not officially expose Peer-Id or Server-Id.  But the 
> certificate subjectAltNames are available via the policy engine.  The greater 
> difficulty is *which* Id to use.
> 
>   RFC 5216 Section 5.2 says:
> 
>It is possible for more than one subjectAltName field to be present
>in a peer or server certificate in addition to an empty or non-empty
>subject distinguished name.  EAP-TLS implementations supporting
>export of the Peer-Id and Server-Id SHOULD export all the
>subjectAltName fields within Peer-Ids or Server-Ids, and SHOULD also
>export a non-empty subject distinguished name field within the Peer-
>Ids or Server-Ids.  All of the exported Peer-Ids and Server-Ids are
>considered valid.

I had missed that part of 5216 before.
While you're mostly stuck doing that sort of "all names in the cert are
deemed valid" for the TLS client certificate, since the server just asks
for *some* cert and has to handle what it gets back, that's not the normal
pattern for authenticating the server.  Consider, e.g., the RFC 6125
procedure, which takes as input to validation the name that the TLS client
was attempting to initiate communication towards.  Depending on the
application protocol that might be a DNS-ID or URI-ID or whatever, but
there's still a clear "I initiated communication towards this specific
named entity; can the server prove that it is that entity" which is very
much not "they proved possession of the private key; all names are
verified".  Even for the same server and same certificate, the answer can
be different for different names in the certificate.  (I am about to clear
a DISCUSS position on draft-ietf-quic-http for just this topic; the
historical HTTP semantics are in line with RFC 6125.  It is perhaps not
strictly required that the EAP usage do the same, but it is surprising, at
least.)

> > and it may be difficult to implement in practice due to ordering.  It might 
> > be simpler to just specify that the end entity peer and client certificates 
> > are used in the key derivation.  Most libraries provide APIs to get the raw 
> > certs.
> 
>   Yes.  We expose the certs to the policy engine, along with various fields.  
> Having the TLS exporter use more data should just be about updating some code.

I think that you get better security properties if you include the entire
certificates, but even just identities are better than nothing (provided
there is a clear unique ordering/encoding, as you note).

-Ben

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

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

Hi Alan,

I'll second the thanks for putting this together; I think it covers the
important open points.

I did belatedly remember one more thing that is perhaps not critical, but
would also be good to get an answer for:

On Fri, Jan 29, 2021 at 03:00:51PM -0500, Alan DeKok wrote:
[...]
> 
> DISCUSS: other than word-smithing the above points, are there serious 
> objections to the behaviour documented in -13?  i.e. does the IETF want to 
> recommend that EAP-TLS alpha testing begins *now*, or should it wait until 
> 2022?

I think that an exchange between Martin and Mohit raised the question of
whether the EAP server-id and peer-id would be available for use in the
'context' argument of the TLS Exporter, as that would help strengthen the
binding between keys and the authentication exchange.
I do recall a mention that WolfSSL doesn't support a context argument for
the exporter, but I don't know how prohibitive that limitation would be in
practice.

-Ben

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

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

On Mon, Feb 01, 2021 at 06:21:16AM +, Peter Gutmann wrote:
> Alan DeKok  writes:
> 
> >OpenSSL has a feature SSL_MODE_AUTO_RETRY which makes it process TLS messages
> >*after* the Finished message. i.e. the Session Ticket, etc. When an
> >application calls SSL_Read(), all of the TLS data is processed, instead of
> >just the "TLS finished" message. They've made this the default, because most
> >applications get it wrong.
> 
> Asking as the author of a TLS library that has always done this, why would you
> stop immediately after the Finished and leave metadata messages sitting unread
> in the input stream?  Was it just some arbitrary implementation decision, or
> is there a technical reason for it?

I expect (but did not attempt to validate) that this was SSLeay-vintage logic
involving only reading a single record from the wire per call to
SSL_read().  If that record was a handshake record and not application
data, well, then the SSL_read() didn't do something useful and so the
special "try again" code was returned and the application was supposed to
call SSL_read() again.

There's no technical reason that I'm aware of.

-Ben

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

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

Hi Alan,

With my apologies to everyone on the thread for so many mails in
succession...

On Fri, Jan 29, 2021 at 02:09:09PM -0500, Alan DeKok wrote:
> On Jan 29, 2021, at 1:32 PM, Benjamin Kaduk  wrote:
> > With respect to the exporter usage, I do see you had asked about using the
> > type-code as the exporter context value that Martin didn't see much value
> > in, but I am willing to accept that as a boon for safety of portability to
> > other TLS-using EAP mechanisms.
> 
>   OK. 
> 
> >  (I do note that the current editor's copy
> > shows calls to TLS-Exporter() with only two arguments, but three are
> > required; the construction there also seems to include a propspect for
> > violation of the requirement that "one label is not a prefix of any other
> > label" when both regular one-byte and extended type codes are used, but if
> > the type code is meant to be the context argument I believe that risk goes
> > away.)
> 
>   The EAP type codes are one octet: 0x00 through 0xfd.  The "expanded" type 
> codes begin with 0xfe.  So there is no prefix issue, even if the type codes 
> form part of the label.

Ah, of course I should have realized that the 0xfe octet separates them.
You are correct; there is no issue with prefixes, and sorry for the
confusion.

Thanks,

Ben

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

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

Hi Mohit,

The quoting in your note is not coming across usefully in my MUA, so I'm
trimming to (what I think are) just your remarks without other history.

On Fri, Jan 29, 2021 at 07:34:42PM +, Mohit Sethi M wrote:
> Hi Ben,
> 
> RFC 5705 says:
> 
>If no context is provided, it then computes:
> 
>PRF(SecurityParameters.master_secret, label,
>SecurityParameters.client_random +
>SecurityParameters.server_random
>)[length]
> 
>If context is provided, it computes:
> 
>PRF(SecurityParameters.master_secret, label,
>SecurityParameters.client_random +
>SecurityParameters.server_random +
>context_value_length + context_value
>)[length]
> 
> 
> We use only two arguments and say "No context data is used in the TLS 
> exporter interface.". We could show the context argument as empty in the 
> calls to make things clearer. By the way, this is what is done by TEAP also. 
> RFC 7170 says "TEAPv1 makes use of the TLS Keying Material Exporters defined 
> in [RFC5705] to derive the session_key_seed.  The label used in the 
> derivation is "EXPORTER: teap session key seed".  The length of the session 
> key seed material is 40 octets.  No context data is used in the export 
> process."

We're using the TLS 1.3 exporter, though, so the RFC 8446
(https://www.rfc-editor.org/rfc/rfc8446.html#section-7.5) three-argument
form seems most relevant.  Note that there is no difference in TLS 1.3
between an absent context and a zero-length context.

> The change of moving the type-code from the context to the label was made 
> based on your review (comments from Martin) and the fact that some libraries 
> such as wolfssl don't support passing a context (so far). See: 
> https://w1.fi/cgit/hostap/tree/src/crypto/tls_wolfssl.c#n1996

I'm not going to get super hung-up on label vs context (but it's clearly a bug
if WolfSSL doesn't support contexts).  I guess Martin even wanted the type code
to be in the label part in the first place, so having it in the label is
"better"; we just need to actually show that there's an empty context
argument.

> I think there was a misunderstanding that an authenticated signal of 
> authentication completed was needed. Only a signal of no more post handshake 
> messages was needed. I think Alan's summary might also explain the situation 
> better.

I note that Alan seems to also be a bit unclear about exactly what purpose
the commitment message serves; I look forward to seeing how the questions
he has listed get answered.

Thanks,

Ben

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

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

On Sun, Jan 31, 2021 at 09:20:57AM -0500, Alan DeKok wrote:
> On Jan 29, 2021, at 5:00 PM, Joseph Salowey  wrote:
> > DISCUSS: the EAP-TLS draft should also explain that session tickets may be 
> > sent either before or after the 0x00 octet.  Does the packet flow look any 
> > different for the two cases?  If so, what does that mean?
> > 
> > [Joe] I believe the flow of the message flights would be the same, but the 
> > on-the-wire format of those flights could be reversed.  I don't think this 
> > will necessarily cause a problem since the application data is consumed by 
> > the EAP TLS and the NewSessionTicket is consumed by TLS,  However I think 
> > the draft should be clear that this can happen.  
> 
>   I think so, too.

I think we should talk about that, yes.
But I haven't managed to convince myself yet that it is 100% safe in the
face of fragmentation -- can we rule out a case where we end up delivering
an EAP-TLS message that ends exactly at the end of the application data
record (say, if bundled along with the tail end of the server handshake
flight) and there is a NewSessionTicket queued that would get fragmented
into the next EAP-TLS message?

> > DISCUSS: the EAP-TLS draft Section 2.1.1 should be updated to note that 
> > this examples does not include Session Tickets.  Section 2.1.2 should be 
> > updated to note that there are more rounds than for the previous section.
> > 
> > [Joe] Yes.  It might be helpful to say that the commitment message may be 
> > sent before or after the client authentication is verified, but in the case 
> > that resumption is used it will always be after.  
> 
>   I think that's a good idea.  The current draft doesn't make this explicit.
> 
>   But... if the commitment message is sent before the client certificates 
> have been authenticated, what does that commitment message *mean*?
> 
>   i.e. can the server send the commitment message, ignore the client cert 
> information, and send an EAP-Success?  Even if the client certs have expired, 
> been revoked, etc.?  Can the client detect a rogue server which always 
> answers "yes"?

That's a scenario that I was starting to puzzle over this weekend as well
-- with EAP-Success "completely unauthenticated", it would be fairly easy
for an on-path attacker to send the EAP-Success the EAP peer was expecting
and make the EAP peer think things succeeded even if the server had
rejected the client cert.  Now, a server that has rejected the client cert
is hopefully not going to be exporting the keys and continuing to run the
next steps of protocol operation, but to some extent it seems that the
security of the system as a whole relies on the server operating correctly
in this regard.  Strictlys speaking, it need not do so -- we could have
defined a mechanism where the exported keys depend, cryptographically, on
the client authentication flight such that the TLS layer will not produce
the needed keys on failed authentication. [0]

I'm assuming that people will not be terribly keen on switching to such a
scheme given that (AFAIK) it would require defining a new TLS 1.3 Exporter
variant that includes the full transcript hash, [1] not just up to Server
Finished, which would incur at a minimum several months' delay.  It might
be worth asking the teams that did formal analysis work on TLS 1.3 how they
modelled client authentication and what assumptions on server behavior they
made.

So, if we do not wait for a cryptographic method to assure successful
client authentication, and thus are going to be stuck requiring some amount
of trust that the server is doing the right thing with the keys, how is it
different to say that the server is going to not export the keys if the
client authentication fails vs saying that the server is going to not
export the keys if it is not done sending handshake messages?  There is
perhaps some detail in terms of how EAP-TLS interacts with the TLS layer
and what information is available when, but it seems that if you have an
interface with TLS of "provide input bytes; get output bytes out" [2] you
could achieve this by not exporting keys until you've sent all those bytes
into EAP-TLS messages.


>   RFC 4137 (https://tools.ietf.org/html/rfc4137) describes a state machine 
> for EAP peer and server.  Does this work follow that?

A good question!

> > [Joe]  If we are going to make a change in the key derivation we should do 
> > it now.  Personally, I think we should update the key derivation to 
> > separate the MSK and EMSK, but it is workable as is.  
> > I think there are potential issues around the ordering of the 0x00 octet 
> > and other messages, but I don't think this will require changes to 
> > implementations in the short term, but the spec needs to clarify this. 
> 
>   I agree.

I wonder if (assuming that 0x00 goes forward instead of "close_notify") we
should also go further and say that this mechanism does not use stock TLS
1.3, but rather a variant of the protocol that imposes an additio

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

Hi Alan,

I see that the thread is continuing and that perhaps my reply will even
become stale as I write it, but I'm replying to your note instead of the
tip of the thread because it has good context for making some broader
points that I would like to make.

On Sat, Jan 23, 2021 at 05:28:10PM -0500, Alan DeKok wrote:
>   We're approaching 2 weeks since the last discussion of this topic.  This 
> document has been in development for 3 years.  We desperately need to finish 
> it.  IMHO waiting another 6 months is not an option.  Even 3 would be 
> worrying.

My understanding of the discussions involving the TLS WG are that we forked
off into two sub-threads: one about the use of TLS Exporters for key
derivation (the one this is a reply to), that largely concluded with
agreement on a simple change to make, and the other sub-thread about the
protocol element known in -13 as the "commitment message".

With respect to the exporter usage, I do see you had asked about using the
type-code as the exporter context value that Martin didn't see much value
in, but I am willing to accept that as a boon for safety of portability to
other TLS-using EAP mechanisms.  (I do note that the current editor's copy
shows calls to TLS-Exporter() with only two arguments, but three are
required; the construction there also seems to include a propspect for
violation of the requirement that "one label is not a prefix of any other
label" when both regular one-byte and extended type codes are used, but if
the type code is meant to be the context argument I believe that risk goes
away.)

With respect to the "commitment message", I thought we had a discussion
that revealed that the mechanism in the -13 could not fulfil its stated
purpose, and that also called into question whether that stated purpose was
actually the right thing that the protocol needed.  My understanding,
therefore, was that the TLS WG could not contribute further insight until
there was a revised proposal from people who understand the needs of the
EAP-TLS protocol from TLS that would both satisfy the needs of EAP and
actually be achievable.

>   We have multiple inter-operable implementations which have implemented 
> draft-13.  That work over the last few months have resulted in implementors 
> making plans to do beta testing in the next few weeks.  Those plans have been 
> put on indefinite hold, due to the recent request for changes.
> 
>   I understand getting feedback from the TLS WG is useful.  But I would 
> prefer to have consensus on a *solution*. Right now, we just have a series of 
> proposed changes, with little to no discussion.

I think this is becaues the TLS WG members (in aggregate) do not have a
clear picture of what property or properties EAP-TLS will require from TLS
that led to the need for an additional message when using TLS 1.3 as
opposed to the RFC 5216 case with TLS 1.2.  The prospect of an
"authenticated signal from TLS to EAP-TLS that the authentication completed
successfully" was mentioned, but I did not have the sense that there was
universal agreement of that as the sole relevant property.

>   We're getting to the point where we have to ship code as promised to 
> customers soon (weeks, not months).  We therefore need consensus, as soon as 
> possible.
> 
>   My preference is to implement draft-13.  We know the code works.  People 
> are ready to ship it.  Any changes will add not just more months of standard 
> discussion, but more months of interoperability testing.
> 
>   If there is no progress in EMU, we're looking at September for first betas. 
>  With no guarantee that there won't be further changes made after that.
> 
>   So the question is:
> 
> * are the draft-13 0x00 byte and exporter *terrible* enough to delay the 
> standard another 6 months?

Well, the text of the -13 contains a protocol mechanism that cannot deliver
its stated purpose, so I will continue to hold a Discuss position if that
remains.  One Discuss ballot does not have to block the work indefinitely
(the shepherding AD can request a different IESG balloting procedure be
used), and I leave it between the WG and Roman whether to attempt that
route.  It is perhaps possible that (as John noted downthread) the text
about the commitment message was badly written, and that just changing the
surrounding description could work, but that gets back to the question I
mentioned above of what properties EAP-TLS actually requires from TLS.

-Ben

> * if the answer is "no", then we can ship now.
> 
> * if the answer is 'yes", then the next question is "when can we get this 
> finalized?"  "March" would be late.  "July" is a major problem.
> 
> > On Jan 12, 2021, at 10:22 AM, Alan DeKok  wrote:
> > 
> > On Jan 11, 2021, at 7:08 PM, Martin Thomson  wrote:
> >> I was not exactly.  I was thinking that EAP-TLS uses the unadorned string 
> >> and other usages (that need a different MSK) define their own string as 
> >> needed.
> > 
> >  Which is largely what was done for <= TLS 1.2.

Re: [TLS] QUIC changes "early_data" extension semantics (Re: Benjamin Kaduk's Discuss on draft-ietf-quic-tls-33: (with DISCUSS and COMMENT))

[Benjamin Kaduk]

Hi Mikkel,

I suspect I'm misunderstanding something, because it sounds to me like you
are supporting a dedicated "quic_early_data" extension to help decouple QUIC
from TLS.  More inline...

On Thu, Jan 07, 2021 at 04:14:05PM +0100, Mikkel Fahnøe Jørgensen wrote:
> 
> 
> > On 7 Jan 2021, at 07.26, Benjamin Kaduk  wrote:
> > 
> > It seems like only QUIC internals would have to change, not TLS internals?
> > 
> > My expectation is roughly that, if we were to compare the work needed to go
> > from (has TLS 1.3 implementation) to (has QUIC implementation that uses
> > quic_early_data instead of early_data) with the work needed to go from (has
> > TLS 1.3 implementation) to (has QUIC implementation as currently
> > specified), there would not be much difference.  Obviously if you are
> > starting from (has QUIC implementation as currently specified), things are
> > different, especially if you want to be able to support both draft QUIC and
> > RFC QUIC in the same codebase.  I still think that things are cleaner with
> > a separate extension and won't involve trying to smush together two things
> > that are mostly, but not entirely, the same, but I'm not going to hold a
> > Discuss over it.
> 
> The concern is also the QUIC v1 uses TLS 1.3 but QUIC as a concept is not 
> heavily tied to a specific crypto paradigm. TLS 1.3 provides the handshake 
> and the transport keys, but QUIC handles all of its own session encryption 
> with or without help from a TLS library. On a practical level this can also 
> helps performance optimizations in software and in hardware.

Yes.  This is what I mean by QUIC 0-RTT and TLS 0-RTT being different --
TLS provides keys, but the actual data handling is done by QUIC.  Using the
TLS mechanism to negotiate TLS early data as an indication that QUIC early
data should be used seems to needlessly couple TLS and QUIC for little
gain.

> From a TLS perspective it may seem reasonable to use the designed feature 
> set, but from a QUIC perspective, QUIC does not necessarily benefit from a 
> tight coupling as long as it can get the keys that it needs. This separation 
> makes it simpler to evolve new versions of QUIC with different crypto designs.
> 
> For example, a given TLS library might not support many-core optimizations 
> and this also isn’t critical for obtaining traffic keys, but a large volume 
> of early data could be processed on 24 separate cores in parallel. Getting 
> that to work with any run of the mill TLS library could be a challenge.

This just seems to be reconfirming that TLS only provides keys to QUIC but
doesn't do any of the bulk-data-handling work.  So a flag that tells TLS
"give me QUIC 0-RTT keys" would work just fine, and there's no reason to
make it be the same flag that says "do TLS 0-RTT".

-Ben

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

Re: [TLS] Martin Duke's Discuss on draft-ietf-tls-external-psk-importer-06: (with DISCUSS)

[Benjamin Kaduk]

On Mon, Jan 04, 2021 at 03:40:34PM -0800, Martin Duke via Datatracker wrote:
> Martin Duke has entered the following ballot position for
> draft-ietf-tls-external-psk-importer-06: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-importer/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> This is probably just my own ignorance, but I see two potential problems in 
> Sec
> 4.1.
> 
> - 'The identity of "ipskx" as sent on the wire is ImportedIdentity, i.e., the
> serialized content of ImportedIdentity is used as the  content of
> PskIdentity.identity in the PSK extension.' IIUC ImportedIdentity has a 
> maximum
> length of 2^17 + 2. But the Identity field in the PSK option has a maximum
> length of 2^16-1. I presume this never actually happens, but the spec should
> handle the boundary condition, perhaps by limiting the first two fields of
> Imported Identity to sum to 2^16-5 bytes or something.

I'll leave this one for the authors.

> - It says 'Endpoints SHOULD generate a compatible "ipskx" for each target
> ciphersuite they offer.' but then the example shows two ciphers that equire
> only one derived key. Do you mean "hash algorithm" instead of "ciphersuite"?
> TLS_AES_128_GCM_SHA256 and TLS_CHACHA20_POLY1305_SHA256 are different
> ciphersuites according to RFC 8446.

TLS 1.3 ciphersuites are associated with a Hash, and 8446 assumes that HKDF
with that Hash is the KDF for use of that ciphersuite.  This document
somewhat extends that to allow a more generic KDF, rather than just HKDF,
but "compatible with a ciphersuite" means "compatible with the KDF
associated with the ciphersuite", and since the Hash and HKDF are the same
for the two ciphers, the same ipskx works for both (and an efficient
implementation would be expected to only compute it once).

Thanks,

Ben

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

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

On Tue, Jan 05, 2021 at 10:41:50AM -0500, Alan DeKok wrote:
> On Jan 5, 2021, at 4:47 AM, Mohit Sethi M  wrote:
> > What I am gathering is that this commitment message should instead be 
> > made into a confirmation message, i.e. it should only be sent after 
> > receiving TLS Finished from the client? This would result in one extra 

I forget if it has been explicitly mentioned in the thread so far, but
https://tools.ietf.org/html/rfc8446#section-4.4.4 is pretty clear that
"Servers MAY send data after sending their first flight, but because the
handshake is not yet complete, they have no assurance of either the peer's
identity or its liveness (i.e., the ClientHello might have been replayed)."
In particular, "no assurance of the peer's identity" means that the server
is at this point sending to an unauthenticated client.  If the goal of
EAP-TLS is to ascertain that there is in fact an authenticated client, it
may be ill-advised to send indications of overall success to an
unauthenticated client.  Part of what Martin alluded to with the situation
being lousy overall is that there are basically two things that can
cryptographically confirm that the client has authenticated: successful
processing of the client Finished, and values derived from the resumption
master secret.  In "normal" TLS usage the server will bail out if the
client Finished doesn't validate, so continued receipt of application data,
including application data bearing application-protocol responses to data
the client sent in 1-RTT after client Finished, effectively implies that
the server validated the client Finished, but the EAP-TLS usage is quite
different from that.  There's not a cryptographic way to tell whether 0x00
application data was generated before or after the client Finished was
processed.

> > round trip to both figure 1 and 3 in the current draft. So we would end 
> > up with the same number of messages as RFC 5216 for full authentication 
> > (https://tools.ietf.org/html/rfc5216#section-2.1.1) and actually do 
> > worse than RFC 5216 (one extra round trip) in case resumption 
> > (https://tools.ietf.org/html/rfc5216#section-2.1.2).
> 
>   That sounds right.

While counting arrows in the diagram like this is definitely useful, part
of my concerns related to the need (in non-resumption flows) to convey the
entire (enlarged) server Certificate chain in individual 1020-byte
EAP-Requests.  My understanding was that the server had to send a single
1020-byte EAP-Request and wait for the corresponding EAP-Response before
sending the next chunk of the certificate chain.  It was in that scenario
that I expected a substantial difference between resumption and
non-resumption.

> > Maybe this is acceptable? The draft anyway notes that "Sending the 
> > Commitment Message in a separate EAP-Request adds an additional 
> > round-trip, but may be necessary in TLS implementations that only 
> > implement a subset of TLS 1.3.". In which case, I am not sure if the 
> > reasons against using close_notify apply anymore.
> 
>   I won't offer opinions on TLS internals, as I'm out of my depth there.
> 
>   As an implementor, the priority is getting TLS alerts (expired cert, etc.) 
> back from the EAP server to the EAP peer.  Those messages can then be used to 
> debug deployment issues.
> 
>   The exact method of doing this is less important.  The "0x00" octet works 
> now, so I'm happy with it.  But if TLS review decides that should change, 
> that's fine, too.

It's pretty much guaranteed that we can get the TLS alerts if we always
wait for client Finished to be processed (whatever signal we end up
choosing to send after that occurs).  Have we reached agreement on whether
we should always wait for client Finished?

-Ben

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

Re: [TLS] QUIC changes "early_data" extension semantics (Re: Benjamin Kaduk's Discuss on draft-ietf-quic-tls-33: (with DISCUSS and COMMENT))

[Benjamin Kaduk]

On Thu, Jan 07, 2021 at 04:11:22PM +1100, Martin Thomson wrote:
> I'm not sure that the other discussions are productive any more, so I'll fix 
> my errors...
> 
> On Thu, Jan 7, 2021, at 15:04, Benjamin Kaduk wrote:
> 
> > > This isn't an "Updates: X" moment at all in my view.  Extensions to TLS 
> > > have added new handshake messages (certificate status for instance) 
> > > without updating what it means to implement the core protocol.  It's only 
> > > an update in my view if the functions defined in the updated document.
> > 
> > (incomplete?)
> 
> Sorry, ... if the functions in the update alter the operation of the core 
> protocol in ways that the core protocol does not anticipate or allow.

Okay, thanks.  8446 doesn't anticipate changes to EndOfEarlyData for
TCP+TLS, but this is ... not that.

> For TLS extensions can (and have) changed all sorts of stuff.

It has not always gone smoothly...

Anyway, I propose that we proceed with your suggestion of (roughly)
"including the 'quic_transport_parameters' extension in EncryptedExtensions
suppresses the requirement to send EndOfEarlyData otherwise implied by
sending 'early_data' in EncryptedExtensions".

> > > I referred to all of the code that involves 0-RTT.
> > 
> > At what layer?  I honestly do not understand which parts you see as "the
> > same behavior".  The application will have some data to send early, sure,
> > but at some point your interface has to know if it's running over TCP+TLS
> > or over QUIC, and the only differences I see are below that point.  Any
> > given TLS handshake is intrinsically destined for QUIC or not-QUIC, so
> > you're never in a situation where you would send both extensions at the
> > same time.
> 
> I was largely referring to the TLS internals that would change if early data 
> was conditioned on a second extension.  It's not a big change, but it would 
> definitely be a difficult one to get right.  My guess is that 0-RTT accounts 
> for about half of the complexity of TLS 1.3 in our stack.  0-RTT in QUIC is 
> relatively easy once TLS has it (it only took me a few hours to implement, 
> from memory).

It seems like only QUIC internals would have to change, not TLS internals?

My expectation is roughly that, if we were to compare the work needed to go
from (has TLS 1.3 implementation) to (has QUIC implementation that uses
quic_early_data instead of early_data) with the work needed to go from (has
TLS 1.3 implementation) to (has QUIC implementation as currently
specified), there would not be much difference.  Obviously if you are
starting from (has QUIC implementation as currently specified), things are
different, especially if you want to be able to support both draft QUIC and
RFC QUIC in the same codebase.  I still think that things are cleaner with
a separate extension and won't involve trying to smush together two things
that are mostly, but not entirely, the same, but I'm not going to hold a
Discuss over it.

> > For what little it's worth, the patches to enable building a QUIC stack on
> > top of OpenSSL (that have been rejected by upstream at this point in the
> > 3.0.0 release cycle and are now maintained by Akamai and used by several
> > parties) don't implement support for early data at all, so I don't have any
> > direct implementation insight to provide.  OTOH, that suggests that people
> > might not be using QUIC 0-RTT with the openssl TLS stack at all.
> 
> 0-RTT is a feature that isn't uniformly supported (I don't think that Google 
> implementations have support yet, though I could be wrong).  It's in Firefox 
> and awesome though.

My data from a couple months ago is that google does QUIC 0-RTT but not TLS
0-RTT, if I'm reading my notes properly.

-Ben

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

Re: [TLS] QUIC changes "early_data" extension semantics (Re: Benjamin Kaduk's Discuss on draft-ietf-quic-tls-33: (with DISCUSS and COMMENT))

[Benjamin Kaduk]

On Thu, Jan 07, 2021 at 02:50:43PM +1100, Martin Thomson wrote:
> Trimming this down.
> 
> On Wed, Jan 6, 2021, at 14:53, Benjamin Kaduk wrote:
> > I didn't expect to find much appetite for changes, but I wouldn't be doing
> > my job if I didn't ask the question.  It's a little unusual for something
> > outside the core protocol to change the behavior of an extension defined in
> > the core protocol, but perhaps not unheard of.  There is also the question
> > of whether it would merit an "Updates:" relationship ... since you have to
> > implement the rest of the new thing to get the new semantics, it may not be
> > needed.
> 
> This isn't an "Updates: X" moment at all in my view.  Extensions to TLS have 
> added new handshake messages (certificate status for instance) without 
> updating what it means to implement the core protocol.  It's only an update 
> in my view if the functions defined in the updated document.

(incomplete?)

> > Which behavior is that, exactly?  The QUIC 0-RTT keys are different than
> > the TLS ones, and the data itself is carried in a different place...
> 
> I referred to all of the code that involves 0-RTT.

At what layer?  I honestly do not understand which parts you see as "the
same behavior".  The application will have some data to send early, sure,
but at some point your interface has to know if it's running over TCP+TLS
or over QUIC, and the only differences I see are below that point.  Any
given TLS handshake is intrinsically destined for QUIC or not-QUIC, so
you're never in a situation where you would send both extensions at the
same time.

> > I think the key question for the TLS WG might be how similar something has
> > to be before it's a good idea to reuse an extension codepoint vs. getting a
> > new one.
> 
> If you like.
>  
> > For what little it's worth, the patches to enable building a QUIC stack on
> > top of OpenSSL (that have been rejected by upstream at this point
> 
> (incomplete?)

Yes, sorry -- interrupted mid-compose.

For what little it's worth, the patches to enable building a QUIC stack on
top of OpenSSL (that have been rejected by upstream at this point in the
3.0.0 release cycle and are now maintained by Akamai and used by several
parties) don't implement support for early data at all, so I don't have any
direct implementation insight to provide.  OTOH, that suggests that people
might not be using QUIC 0-RTT with the openssl TLS stack at all.

-Ben

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

[TLS] QUIC changes "early_data" extension semantics (Re: Benjamin Kaduk's Discuss on draft-ietf-quic-tls-33: (with DISCUSS and COMMENT))

[Benjamin Kaduk]

Changing Subject: and adding tls@ ...

On Wed, Jan 06, 2021 at 02:04:02PM +1100, Martin Thomson wrote:
> Hi Ben,
> 
> I'm going to respond here to your DISCUSS points, but leave the comments to 
> our issue tracker.  Lucas has volunteered to do transcription for that.

Sounds good.

> On Tue, Jan 5, 2021, at 15:53, Benjamin Kaduk via Datatracker wrote:
> > (1) Rather a "discuss-discuss", but we seem to be requiring some changes
> > to TLS 1.3 that are arguably out of charter.  In particular, in Section
> > 8.3 we see that clients are forbidden from sending EndOfEarlyData and it
> > (accordingly) does not appear in the handshake transcript.  The
> > reasoning for this is fairly sound; we explicitly index our application
> > data streams and any truncation will be filled in as a normal part of
> > the recovery process, so the attack that EndOfEarlyData exists to
> > prevent instrinsically cannot happen.  However, the only reason we'd be
> > required to send it in the first place is if the server sends the
> > "early_data" extension in EncryptedExtensions ... and we already have a
> > bit of unpleasantness relating to the "early_data" extension, in that we
> > have to use a sentinel value for max_early_data_size in NewSessionTicket
> > to indicate that the ticket is good for 0-RTT, with the actual maximum
> > amount of data allowed indicated elsewhere.  TLS extensions are cheap,
> > so a new "quic_early_data" flag extension valid in CH, EE, and NST would
> > keep us from conflating TLS and QUIC 0-RTT semantics, thus solving both
> > problems at the same time.  On the other hand, that would be requiring
> > implementations to churn just for process cleanliness, so we might also
> > consider other alternatives, such as finessing the language and/or
> > document metadata for how this specification uses TLS 1.3.
> > (There are a couple other places in the COMMENT where we might suffer
> > from scope creep regarding TLS behavior as well, but I did not mark them
> > as DISCUSS since they are not changing existing specified behavior.)
> 
> I don't think that you will find much appetite for changes.  However, I think 
> that your suggestion here shows how we can rationalize the change: 
> negotiating the quic_transport_parameters extension results in the 
> suppression of EndOfEarlyData.  No need for any additional extensions.

I didn't expect to find much appetite for changes, but I wouldn't be doing
my job if I didn't ask the question.  It's a little unusual for something
outside the core protocol to change the behavior of an extension defined in
the core protocol, but perhaps not unheard of.  There is also the question
of whether it would merit an "Updates:" relationship ... since you have to
implement the rest of the new thing to get the new semantics, it may not be
needed.

> Having been responsible for implementing a lot of TLS early data and the QUIC 
> extensions, I can say that your suggestion would be more difficult to manage, 
> because it requires checking two different extensions that independently 
> govern the same behaviour.  (I would concede that I did make some 
> architectural choices that are questionable in light of the above 
> rationalization, but my point stands nonetheless.)

Which behavior is that, exactly?  The QUIC 0-RTT keys are different than
the TLS ones, and the data itself is carried in a different place...

I think the key question for the TLS WG might be how similar something has
to be before it's a good idea to reuse an extension codepoint vs. getting a
new one.

> From a process perspective, if you consider this change to TLS to be out of 
> scope, even though it is specifically limited to QUIC's usage of TLS, then 
> I'm happy to have the TLS working group discuss the change.  It is true that 
> this extension does alter the protocol in a non-trivial way, so requesting 
> specific review is sensible.

I don't think that an argument about "out of scope" is going to be a
particularly useful use of anyone's time, though I do want to see if
framing the question in this way elicits any responses from the TLS WG
(cc'd).

> I will be strongly advocating for no change, of course.  I will note that we 
> did circulate the draft for review already and this issue did not arise, nor 
> did it arise as it was implemented in many stacks, so I would not expect 
> there to be much support for a different design.

I don't want to let process wonkery derail the running code, so hopefully
it is just a short discussion.
For what little it's worth, the patches to enable building a QUIC stack on
top of OpenSSL (that have been rejected by u

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

On Tue, Jan 05, 2021 at 11:12:21AM -0500, Alan DeKok wrote:
> On Jan 5, 2021, at 11:05 AM, Michael Richardson  wrote:
> > 
> > Alan DeKok  wrote:
> >> Therefore, we need an explicit signal to the EAP-TLS layer that the
> > 
> > Do you mean, "to the EAP layer"?
> > s/EAP-TLS layer/EAP/ ??
> 
>   If the EAP-TLS layer allows TLS negotiation OR EAP-Success, then it's 
> possible to bypass TLS by spoofing an EAP-Success.  So the EAP-TLS layer 
> needs to have a way to say "we're done, EAP-Success is now OK".
> 
>   It's really nested:  EAP ( EAP-TLS ( TLS ) ) 
> 
>   We can't finish EAP until we know that EAP-TLS is finished.  We can't 
> finish EAP-TLS until we know that TLS is finished.

Okay.  What step suffices to determine that "TLS is finished" for your use
case.  The natural definition is "the handshake is complete", which would
be incompatible with the text currently in the draft (and with 0.5-RTT
entirely).

-Ben

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

Re: [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

On Mon, Jan 04, 2021 at 02:44:01PM +1100, Martin Thomson wrote:
> 
> I would instead either prohibit the use of application data outright or say 
> that it carries no semantics unless otherwise negotiated.  The current design 
> has the effect of rendering application data unusable, so perhaps the former 
> is best.

The "rendering application data unusable" bit is something that bothered me
a lot as well.  While banning application data is okay for EAP-TLS itself
(AIUI), the document implies that other TLS-based EAP mechanisms do need to
convey application data, and I think that the responsible thing to do is
ensure that the machinery we use here would be compatible with those other
EAP mechanisms with no, or only minimal, changes.

> # Key Schedule
> 
> The other thing I observe is the way that this slices up the exporter output. 
>  This was something that old versions of TLS did, but TLS 1.3 did away with.  
> Though RFC 5216 did this, EAP-TLS for TLS 1.3 doesn't need to.  This could - 
> and should - do the same.  All it means is having more exporter labels.
> 
> I appreciate that this uses exporters now rather than abusing the internal 
> PRF.  That's good.  The next step is to dispense with the intermediate values 
> (Key_Material, MSK, EMSK, IV) and all the slicing that occurs and use the TLS 
> exporter for each of the six values that the protocol requires.  I also note 
> that the 0x0D value is used multiple times, unnecessarily, both as a context 
> strong to the exporter and as a prefix to the session ID.

I think Alan explained the dual purpose of the Type-Code here.  (I myself
had missed the connection of where the 0x0d value came from, and a
reference for that seems like it would be helpful, as setting up this
machinery for reuse by other mechanisms in a way that provides key
separation.)

-Ben

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

Re: [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

On Tue, Jan 05, 2021 at 10:26:40AM +1100, Martin Thomson wrote:
> On Mon, Jan 4, 2021, at 21:01, Mohit Sethi M wrote:
> > >  I have a much simpler one: the EAP layer has a signal that the 
> > >  protocol is complete: EAP-Success 
> > Alan Dekok explained in a separate email thread why this is not the 
> > case 
> > (https://mailarchive.ietf.org/arch/msg/emu/uMNKV_vfov7ASob6_Qu3FlCNcT0/). 
> > He wrote: "The EAP-Success and EAP-Failure messages are *not* protected.  
> > i.e. they are 4-bytes of data which can be spoofed rather trivially.". 
> 
> I specifically addressed that point in my original email.  My assertion was 
> that this is not an significant concern.
> 
> Your point about reliability is confusing.  I've read Section 4.2 of RFC 3748 
> and while it says "A peer MUST allow for this circumstance as described in 
> this note.", I see no explanation of how to concretely make that allowance.  
> Are you saying that EAP methods don't really use EAP-Success and condition 
> their behaviour on other signals?  For TLS 1.3, where the server indicates 
> success before the client, I can see how you might want a reliable 
> confirmation that the server has accepted the client Finished.
> 
> As an aside, this makes is clear that the signal does not exist for the 
> reason implied by the draft.  It does not exist to signal that the TLS 
> messages are done; it exists to signal that the server has received and 
> accepted the client Finished.  To that end, it's not really a layering 
> violation in the sense that Ben describes.  The layering violation exists 
> only because of the language constraining what TLS does thereafter; in that 
> case, a language cleanup might be enough to address the concerns.
> 
> Note however, that the proposed design does not guarantee that a Confirmation 
> Message acknowledges the client Finished.  The server can send the proposed 
> Confirmation Message before the client completes the handshake.  
> 
> Echoing the client Finished might help, but that's a layering violation too.  
> Ideally you would be able use something like exporters to help, but those 
> have problems (see below).  I know it's a knee-jerk, but the idea of making 
> EAP-Success reliable is far more appealing to me than anything you suggest.
>  
> > I also think that this should not be treated as an issue for EAP-TLS 
> > only. I can imagine other deployments which use TLS for making 
> > authorization decisions but do not use the TLS for sending message. So 
> > I am glad that Ben has brought this to the TLS working group for 
> > further discussion. Whether we use this 1-byte of application data (as 
> > done in this draft) or some other mechanism (such as close_notify), we 
> > need a reliable way of telling that no further post handshake messages 
> > will be sent. 
> 
> EAP has the privilege of being the first to grapple with this.
> 
> I'm going to suggest something slightly scandalous: TLS 1.3 exporters are not 
> the ideal design.  They should have included the full handshake transcript, 
> just like the resumption secret.  There were good reasons at the time for 
> designing them as they are, and there are likely reasons to retain the 
> current design as an option (it's stronger than the early exporter and there 
> might be use cases), but those original reasons are less relevant.  The 
> current design gives short shrift to client authentication, to the detriment 
> of use cases like EAP.

I was just grappling with this topic recently in a different context.  I
agree that it would be good to have at least some version of an exporter
available that includes the full transcript's hash in the context.  It
seems to have made some implicit assumptions about how TLS is used (to
carry application data, not as a key-exchange or authentication mechanism)
and how TLS records are carried (over TCP, which serializes handshake
messages and application data; not the case for QUIC) that are causing
problems for us now.

That said, it doesn't seem like it would be *terribly* complicated to
specify a new type of exporter interface that does use the full transcript.
It might have to be TLS 1.3+ only, and getting the IANA considerations
right might be gnarly, but the core of it seems pretty simple.

> Having exporters depend on the entire transcript would serve EAP better.  In 
> this case, you could provide an application-level signal using an exported 
> value.
> 
> Without that sort of in-TLS affordance, confirming receipt of the client 
> Finished might do.  You still have the possibility that the server doesn't 
> depend on client authentication and so predicts the value, but that would be 
> true of a full-transcript exporter too, so arguably that doesn't matter.

If there truly is a need for a signal from TLS to not generate more
handshake messages (including to tear down the connection if KeyUpdate
would be needed), that seems like it is arguing for a new TLS handshake
message.  I am not 100% sure whether th

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

Hi Martin,

Thanks for chiming in here; your insight has been quite helpful already.
(I am going to reply to the thread in reverse order so as to not duplicate
what you've already said.)

On Tue, Jan 05, 2021 at 02:50:15PM +1100, Martin Thomson wrote:
> Hi Alan,
> 
> On Tue, Jan 5, 2021, at 14:05, Alan DeKok wrote:
> > On Jan 4, 2021, at 6:26 PM, Martin Thomson  wrote:
> > > Your point about reliability is confusing.  I've read Section 4.2 of RFC 
> > > 3748 and while it says "A peer MUST allow for this circumstance as 
> > > described in this note.", I see no explanation of how to concretely make 
> > > that allowance.  Are you saying that EAP methods don't really use 
> > > EAP-Success and condition their behaviour on other signals?
> > 
> >   EAP-Success by itself is *not* a reliable indication of Success.  See 
> > RFC 3748 Section 4.2:
> > 
> >Success and Failure packets MUST NOT be sent by an EAP authenticator
> >if the specification of the given method does not explicitly permit
> >the method to finish at that point.
> 
> This is fine.  What you might be concerned about is the nature of the signals 
> that the EAP authenticator is receiving from TLS.  What you had in the case 
> of TLS 1.2 was the stack providing bytes to send (which were to go in 
> EAP-Request) and then, after everything is done, a positive signal saying 
> that the handshake was complete and satisfactory.  That latter signal is the 
> important one.

Yes.  Part of what had me so unhappy about this document is that the
Commitment Message is discussed only as a "promise to not send more
handshake messages", not "an indication that the handshake is complete and
the TLS layer is happy".  (Furthermore, what Alan writes below about
"cannot distinguish a "finished authentication" EAP-Success from a
"spoofed" EAP-Success" really needs to make its way into the document.)

> TLS 1.3 muddies things by allowing bytes to be sent *after* the 
> complete+satisfactory signal from TLS.  That's what you are grappling with 
> here.  What I'm suggesting is that you don't rely on looking at what bytes 
> hit the wire, but wait until two conditions are complete:
> 
> 1. The TLS stack says that it is content: the handshake is complete and it is 
> OK with whatever the other side has provided.
> 2. The TLS stack has no more bytes to send.
> 
> The latter is likely where the confusion comes from, but if the stack doesn't 
> produce bytes when you give it bytes, then you don't need to keep waiting.  
> For what you depend on, that's enough.

I agree that this is probably good enough.  There may be some complications
depending on how badly the availability of session resumption is desired (I
know OpenSSL provides an API to let the application requst a new session
ticket regardless of whether any were sent with the initial handshake -- I
wrote it -- though I need to tweak it so that it will not always wait for
application data to send before sending the ticket), but I believe this
provides the key functionality.

> The mistake with sending application data is that there is no obligation on 
> the part of the TLS stack to order its sending of NewSessionTicket relative 
> to the application data.  Nor is is possible for you to correctly distinguish 
> TLS data that contains your Confirmation Message from a record that just 
> contains a little bit of a session ticket.  But you don't need to worry about 
> that.
> 
> An example might help illustrate:
> 
> 1. ... many steps occur
> 2. Client sends EAP-Response ending in a TLS Finished.
> 3. Server reads that message, processes it and determines that the handshake 
> is complete and acceptable (e.g., checks the client certificate against its 
> policy).
> 4. As the server is happy, it writes the Confirmation Message to TLS.
> 5. Server asks TLS stack for outstanding data to write; TLS stack provides a 
> bunch of application_data records.

(In particular, this is the TLSCiphext content type that is
"application_data", and the inner content type could be handshake or
application data.  The application doesn't have visibility into it.)

> 6. Server writes TLS records into an EAP-Request and sends it.
> 7. Client receives this and sends an empty EAP-Response.
> 8. Server sends EAP-Success.
> 
> This is, I assume what you intend here, with a little more detail around 
> steps 3-5.  But what happens if the TLS stack prioritizes application data 
> above its own maintenance such that at step 5 the Confirmation Message is 
> written to the wire before the TLS NewSessionTicket?  Is that a problem?  
> What validation is the client expected to perform at step 7?

I would like to see a more precise description of what properties are
actually needed by peer and responder here, yes.  I agree that TLS 1.3 has
changed things compared to 1.2, but the text currently in the draft doesn't
do very well to motivate why this information is important, and (at least
to me) doesn't give a strong enough justification to meri

[TLS] Benjamin Kaduk's Yes on draft-ietf-tls-external-psk-importer-06: (with COMMENT)

[Benjamin Kaduk via Datatracker]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-tls-external-psk-importer-06: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-importer/



--
COMMENT:
--

Sorry about the large volume of comments; this document is actually in
pretty good shape, there are just a bunch of details that can be subtle
to get exactly right.

I specifically call out the note in Section 4.1 about which
HKDF-Expand-Label is to be used, since that would affect the actual
derived keys for DTLS 1.3 (and any hypothetical future TLS versions).

Section 1

   While there is no known way in which the same external PSK might
   produce related output in TLS 1.3 and prior versions, only limited
   analysis has been done.  Applications SHOULD provision separate PSKs
   for TLS 1.3 and prior versions.

   To mitigate against any interference, this document specifies a PSK
   Importer interface by which external PSKs may be imported and
   subsequently bound to a specific key derivation function (KDF) and
   hash function for use in TLS 1.3 [RFC8446] and DTLS 1.3 [DTLS13].  [...]

IIRC the main target use cases for this mechanism are for *existing*
external PSKs (violating the "SHOULD" from the first quoted paragraph),
as well as deployments that are simplified by only needing to provision
a single PSK.  Does it make sense to include such clarifying description
here?  (Similarly, is it accurate to say that "[a]pplications SHOULD
provision separate PSKs [...], but the mechanism defined in this
document provides a partial mitigation for use when that is not possible"?

Also, we only use the word "interference" twice in this document
(this is the first instance), so it might be worth a couple more words
to clarify the nature of the potential interference.

Section 3

   non-imported keys for TLS versions prior to TLS 1.3.  Non-imported
   and imported PSKs are distinct since their identities are different
   on the wire.  See Section 6 for more details.

(side note?) I think the precise story here is a little subtle -- for
any given key, the imported and non-imported identities are distinct,
but in principle one could construct a non-imported identity that
overlaps with an imported identity for a different key (and we say as
much at the end of Section 7).  This is vanishingly rare to happen by
chance, but makes the statement as written not quite categorically true.
That said, the change to the binder key derivation (§ 4.2) seems to
obviate any potential consequences to such a collision (though the
connection attempt would presumably fail).

   Endpoints which import external keys MUST NOT use either the external
   keys or the derived keys for any other purpose.  Moreover, each

IIUC, this is "MUST NOT use the keys that are input to the import
process for any purpose other than the importer, and MUST NOT use the
derived keys for any purpose other than TLS PSKs".  Is it worth spelling
it out explicitly like that?

   external PSK MUST be associated with at most one hash function, as
   per the rules in Section 4.2.11 from [RFC8446].  See Section 7 for
   more discussion.

Does this requirement apply to the inputs to the importer process, the
outputs, or both?

Section 3.1

   *  Imported PSK (IPSK): A PSK derived from an EPSK, External
  Identity, optional context string, target protocol, and target
  KDF.

There is an "External Identity" that is contained within the EPSK
itself; is the "External Identity" listed here distinct from that?

Section 4.1

   The PSK Importer interface takes as input an EPSK with External
   Identity "external_identity" and base key "epsk", as defined in
   Section 3.1, along with an optional context, and transforms it into a
   set of PSKs and imported identities for use in a connection based on
   target protocols and KDFs.  In particular, for each supported target
   protocol "target_protocol" and KDF "target_kdf", the importer
   constructs an ImportedIdentity structure as follows:

If I understand correctly the "target_kdf" is supposed to be the KDF
associated with the cipher suite(s) the derived PSK will be usable for.
This is something of a divergence from RFC 8446, where we *assume* that
the KDF will be HKDF and associate only a *hash function* with the
cipher suite.  While discussing a more generic KDF concept seems
reasonable (and is dire

Re: [TLS] Erik Kline's No Objection on draft-ietf-tls-external-psk-importer-06: (with COMMENT)

[Benjamin Kaduk]

On Mon, Dec 28, 2020 at 10:50:20PM -0800, Erik Kline via Datatracker wrote:
> Erik Kline has entered the following ballot position for
> draft-ietf-tls-external-psk-importer-06: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-importer/
> 
> 
> 
> --
> COMMENT:
> --
> 
> [[ questions ]]
> 
> [ section 4.2 ]
> 
> * I'm insufficiently versed in TLS and HKDF to know for sure, but the text
>   about "replace the string" and the diagrammed example don't seem to agree,
>   **to my untrained eye**.  The example seems to show "imp binder" perhaps
>   concatenated with the "standard" sequence, rather than "imp binder"
>   /replacing/ "ext binder".
> 
>   Am I way off base here? In other words, should
> 
> "ext binder" | "res binder" | "imp binder"
> 
>   actually be (if I understand the use of the word "replace" correctly):
> 
> "imp binder" | "res binder"
> 
>   ?

I guess https://tools.ietf.org/html/rfc8446#section-7.1 does not cover this
very well either, but the '|' notation is just shorthand for "there are
multiple outputs, produced by using the different values as this input
field".  It's not concatenation, just a different output corresponding to
the different case of protocol operation.

Suggestions for how to clarify that would, of course, be most welcome!

Thanks,

Ben

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

[TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

Hi TLS WG,

I'm forwarding my ballot comments on the (now-deferred) EAP with TLS 1.3
draft here, since they relate to some rather core TLS protocol concepts,
and I'd like to get some broader feedback with the extra time given by
deferring the ballot.

Please ensure that comments reach the EMU WG list (cc'd).

Thanks,

Ben

On Wed, Dec 16, 2020 at 02:36:50PM -0800, Benjamin Kaduk via Datatracker wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-emu-eap-tls13-13: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> I'm going to defer this document's evaluation because I think there are
> several interrelated subtle issues that merit closer consideration than
> has been given so far.  I will also invite the TLS WG to provide input
> on these issues, since they relate to rather fundamental issues of the
> operation of the TLS sub-protocols.
> 
> Most of them concern the Commitment Message, in terms of what goals it
> aims to achieve, how it is specified, and what mechanism is used to
> effectuate it.
> 
> To start with the easy one: currently the way in which the structure of
> the Commitment Message is described makes reference to many fields of
> TLS Record Layer structures in order to specify what is fundamentally a
> message on the TLS Application Data stream.  This is a layering
> violation; I don't see any reason to say more than what was suggested in
> https://mailarchive.ietf.org/arch/msg/emu/ECgvnq-C_VVXT5bpvOowte8LBjw/ :
> "the commit[ment] message is a single byte of [value] 0 in the application 
> data
> stream".  All the bits about cryptographic protection and expansion of the
> plaintext in prepararation for record protection are just adding noise,
> and the interface between the TLS stack and the application is supposed
> to be a data-stream abstraction, not a record abstraction.
> 
> Next, the whole reason for the existence of a Commitment Message seems
> under-justified -- the only mention I could find in the document is that
> it serves "to decrease the uncertainty for the EAP-TLS peer".  What harm
> would be caused by a lack of certainty in this area?  Why does waiting
> for an EAP-Success or EAP-Failure not provide a similar level of
> certainty?
> 
> The document also suggests in several places that the Commitment Message
> can or should be sent at 0.5-RTT data in the same flight as the server
> Finished.  The intent, as determined from the mailing list archive,
> seems to be to save a round-trip compared to a typical full message flow
> where the server does not send application data until after the client's
> Finished (and any application data alongside it) is received.  In
> particular, this came out during discussion of how a TLS "close_notify"
> alert would be unsuitable for the role of the Commitment Message, since
> sending the "close_notify" in 0.5-RTT would prevent sending an alert if
> the client authentication failed, and the diagnostic value of such
> alerts is significant.  This is where the issues start to become
> interrelated -- the Commitment Message as a new application-data
> construct is for the objective of reducing the number of round trips.
> However, TLS session resumption is also designed to reduce the number of
> round-trips (including by no longer needing to send potentially large
> TLS Certificate messages that get fragmented at the EAP layer, with the
> cost of a round trip per fragment), and there is a nasty interaction
> between the two mechanisms.  Specifically, TLS 1.3 session resumption
> requires the use of a NewSessionTicket message, which is associated with
> a resumption secret; the resumption secret, in turn, is not available in
> the key schedule until the client Finished (and client authentication
> messages, if any) is available.  While it is possible in many Web
> scenarios for NewSessionTicket to be issued in the 0.5-RTT flight, this
> is because the server can precompute what the valid client Finished
> would be and use that in the key schedule to precompute the resumption
> secret.  If the client is to be authenticated,

Re: [TLS] Murray Kucherawy's No Objection on draft-ietf-tls-ticketrequests-07: (with COMMENT)

[Benjamin Kaduk]

On Sun, Dec 13, 2020 at 10:24:01PM -0800, Murray Kucherawy via Datatracker 
wrote:
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-tls-ticketrequests-07: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Some places in this document use "reuse", others "re-use".  I'm not sure which
> one is right, but it should be consistent throughout.

Both are (or, rather, can be) correct, if you treat "reuse" is a noun and
"re-use" is a verb.

> In Section 3:
> 
>A client starting a new connection SHOULD set new_session_count to
>the desired number of session tickets and resumption_count to 0.
> 
> Since it's only SHOULD, I'm curious about why an implementer might decide to 
> do
> something other than this.

IIRC there's not currently any other behavior that particularly makes
sense, but since we had some extreme contention about sending particular
combinations of values there was not much desire to attempt to nail this
case down.  (It also leaves some flexibility for potential future work,
though I'm not entirely sure what shape that would take.)

-Ben

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

[TLS] Results of Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[Benjamin Kaduk]

Hi all,

Thank you for the robust discussion on this last-call thread (just a bit past
100 messages so far), including the interesting discussion (though arguably a
tangent to the document at hand by the end) about how the IETF can better
provide operational guidance and support robust and sustainable device
ecosystems and lifecycles.  While extended implementation guidance seems out
of scope for this document, reference(s) to such guidance elsewhere may be
useful, if the appropriate material to reference is located.

Though there were some relatively minor issues reported (Tom Petch noted a
botched reference or two, the gen-art and ops-dir reviews found some nits, and
John Klensin advocated for greater clarity on the relationship between RFC
5469 and RFC 5246), the bulk of the discussion focused on the potential harm
that would be caused by an immediate and universal move to TLS 1.2 as the
minimum version of TLS used at runtime or the removal of support for older TLS
versions from major software implementations such as TLS libraries or
browsers.

We heard about many classes of deployed systems that are in practice not
upgradeable (including due to the risk of breakage introduced by the update
process), and the knock-on effects on the local ecosystems that contain such
devices, including both where there are old TLS clients and where there are
old TLS servers, and a desire to have more text to acknowledge these use cases
and potentially indicate workarounds for them.  Many of these facts were
known to and considered by the WG at the decision to go forward with this
document around the time of IETF 102 (the benefits to the ecosystem were
deemed to outweight the breakage that would be incurred), but hearing it
again (and all in one place) is still useful.

We were also reminded that not only does the TLS ecosystem extend beyond the
Web, it also extends even to systems not connected to the Internet and
divorced from domain-name-based X.509 PKIs.  Such systems might (for example)
use RFC 1918 address space with iPAddress certificates, or pinned self-signed
certificates for TLS authentication.

A repeating theme was a desire by some participants to have some text as a
"hook" that indicates to sites that have already-fielded equipment
incompatible with the recommendations of this document that it is okay to
disregard its advice.  Other participants, however, expressed the sentiment
that a clear and unambiguous statement of best practices is preferred, with
many parties (presumably not the same ones that would benefit from the "hook")
having no difficulty in diverging from IETF guidelines.  Sentiments were
especially mixed as to the advisability of attempting to enumerate specific
exception cases where dropping old TLS versions would be harmful, as might
occur in such "hook" text.

There was also a proposal to keep TLS 1.0 and 1.1 enabled but treat it
identically to cleartext, though subsequent discussion concluded that
intentionally setting up a scenario where client and server disagree about
whether or not the traffic is secured seems ill-advised.

We heard about several classes of deployment for which an attempt to make this
change "overnight" would be a non-starter, with lead times measured in years
being necessary in order to achieve changes of this nature.  Fortunately, it
was clarified that publication of this document as a BCP would not require
such instant change; rather, this is the IETF describing what we believe to be
the best practices at the present time, with no immediate obligation to adhere
to such practices.  A transition period for moving from the present state of
any given deployment to the recommended state is called for, and this document
describes the motivation for the change so that each site can make an
assessment of their own risk and exposure, and thus, the pace at which to
transition.

In light of the expressed desire for long lead times in changes of this
nature, the question was raised as to when TLS 1.2 will be due for a similar
treatment, including whether it is advisable to choose and start advertising a
date for such a change now.  I note that TLS 1.3 features significant
improvements over TLS 1.2 on many axes, so I will encourage consideration
of this question in the TLS WG.


In conclusion, my assessment is that there is general IETF consensus to
publish this document in its current form, including the use of "MUST NOT"
language for the old TLS versions.  However, in the interest of clarity, we
should also provide some text to reiterate that this document reflects the
guidance from the IETF as to what are currently believed to be best practices
and why, but that whether or not (and how quickly) to adhere to the
IETF-provided best practices remains at the discretion of implementors and
operators.  Accordingly, I propose to add a new section just before the
Security Considerations section:

%%%

7. Operation

[TLS] Fwd: [kitten] I-D Action: draft-ietf-kitten-tls-channel-bindings-for-tls13-01.txt

[Benjamin Kaduk]

Hi everyone,

As you may recall, RFC 8446 Appendix C.5 has a brief mention that "the
channel bindings described in [RFC5929] are not defined for TLS 1.3" with
no further details.

The draft mentioned below rectifies this situation, defining a tls-exporter
channel binding that should be applicable to all versions of TLS, including
1.3.  It would be great if people could review this (5 page) document over
at kitten@ so that it can move forward -- there is already at least one
draft (draft-ietf-nfsv4-rpc-tls) stuck in the RFC Editor's queue waiting
for it.

Thanks,

Ben

On Wed, Nov 18, 2020 at 06:47:02PM -0800, 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 Common Authentication Technology Next 
> Generation WG of the IETF.
> 
> Title   : Channel Bindings for TLS 1.3
> Author  : Sam Whited
>   Filename: 
> draft-ietf-kitten-tls-channel-bindings-for-tls13-01.txt
>   Pages   : 5
>   Date: 2020-11-18
> 
> Abstract:
>This document defines a channel binding type, tls-exporter, that is
>compatible with TLS 1.3 in accordance with RFC 5056, On Channel
>Binding.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-kitten-tls-channel-bindings-for-tls13/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-kitten-tls-channel-bindings-for-tls13-01.html
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-tls-channel-bindings-for-tls13-01
> 
> 
> 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/
> 
> 
> ___
> Kitten mailing list
> kit...@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten

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

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

[Benjamin Kaduk]

Thanks, authors -- this looks good and I will start the IETF LC.

One nit that can be rolled in with any LC comments: in Section 3,
we say "clients can send a resumption_count equal to the number
of sessions they are attempting in parallel", and "connections"
probably works better than "sessions" in that case.

-Ben

On Thu, Nov 19, 2020 at 04:43:07AM -0800, 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   : TLS Ticket Requests
> Authors : Tommy Pauly
>   David Schinazi
>   Christopher A. Wood
>   Filename: draft-ietf-tls-ticketrequests-06.txt
>   Pages   : 8
>   Date: 2020-11-19
> 
> Abstract:
>TLS session tickets enable stateless connection resumption for
>clients without server-side, per-client, state.  Servers vend an
>arbitrary number of session tickets to clients, at their discretion,
>upon connection establishment.  Clients store and use tickets when
>resuming future connections.  This document describes a mechanism by
>which clients can specify the desired number of tickets needed for
>future connections.  This extension aims to provide a means for
>servers to determine the number of tickets to generate in order to
>reduce ticket waste, while simultaneously priming clients for future
>connection attempts.
> 
> 
> The IETF datatracker status page for this draft is:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/__;!!GjvTz_vk!HB992pPJ1UklR-6jpx1tG6UdM_DlgB6SPZPtSNmS_bsrO7N7osl-ikhC9gmmmA$
>  
> 
> There is also an HTML version available at:
> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-tls-ticketrequests-06.html__;!!GjvTz_vk!HB992pPJ1UklR-6jpx1tG6UdM_DlgB6SPZPtSNmS_bsrO7N7osl-ikgIjKMr6g$
>  
> 
> A diff from the previous version is available at:
> https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-ticketrequests-06__;!!GjvTz_vk!HB992pPJ1UklR-6jpx1tG6UdM_DlgB6SPZPtSNmS_bsrO7N7osl-ikjYYpP9yA$
>  
> 
> 
> 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:
> https://urldefense.com/v3/__ftp://ftp.ietf.org/internet-drafts/__;!!GjvTz_vk!HB992pPJ1UklR-6jpx1tG6UdM_DlgB6SPZPtSNmS_bsrO7N7osl-ikhTz5kGmw$
>  
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!HB992pPJ1UklR-6jpx1tG6UdM_DlgB6SPZPtSNmS_bsrO7N7osl-ikjex2YegA$
>  

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

Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

[Benjamin Kaduk]

On Tue, Nov 17, 2020 at 10:09:34AM +0100, Achim Kraus wrote:
> Hi Ben,
> 
> Am 17.11.20 um 07:07 schrieb Benjamin Kaduk:
> > On Fri, Oct 30, 2020 at 01:28:12PM +0100, Achim Kraus wrote:
> >> Hi Ekr,
> >>
> >>> As for EtM
> >>>
> >>> Encrypt-then-MAC:
> >>> struct {
> >>>     uint8 marker = tls12_cid;
> >>>     uint8 cid_len;
> >>>     uint8 content_type = tls12_cid;      \
> >>>     uint16 DTLSCiphertext.version;       |  appears on wire
> >>>     uint64 seq_num; // includes epoch    |
> >>>     opaque cid[cid_len];                 /
> >>>     uint16 iv_length;
> >>>     opaque IV[iv_length];
> >>>     uint16 enc_content_length;
> >>>     opaque enc_content[enc_content_length];
> >>> };
> >>>
> >>
> >> I failed to understand the reasons behind this proposal.
> >>
> >> 1. Why should the "marker" be added, if the "content_type" is already in
> >> the MAC, and this special MAC is only applied for tls12_cid records.
> >> What is the intended benefit of that?
> >
> > This is another general hygiene item; we are preserving the invariant that
> > the first byte of the MAC input is the content type -- this is at present
> > (IIRC) invariant across all TLS versions and MtE/EtM, and not something to
> > change lightly.
> 
> "All TLS versions"?

Apparently I did not remember correctly.

Sorry about that.

-Ben

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

Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

[Benjamin Kaduk]

On Fri, Oct 30, 2020 at 01:28:12PM +0100, Achim Kraus wrote:
> Hi Ekr,
> 
> > As for EtM
> >
> > Encrypt-then-MAC:
> > struct {
> >    uint8 marker = tls12_cid;
> >    uint8 cid_len;
> >    uint8 content_type = tls12_cid;      \
> >    uint16 DTLSCiphertext.version;       |  appears on wire
> >    uint64 seq_num; // includes epoch    |
> >    opaque cid[cid_len];                 /
> >    uint16 iv_length;
> >    opaque IV[iv_length];
> >    uint16 enc_content_length;
> >    opaque enc_content[enc_content_length];
> > };
> >
> 
> I failed to understand the reasons behind this proposal.
> 
> 1. Why should the "marker" be added, if the "content_type" is already in
> the MAC, and this special MAC is only applied for tls12_cid records.
> What is the intended benefit of that?

This is another general hygiene item; we are preserving the invariant that
the first byte of the MAC input is the content type -- this is at present
(IIRC) invariant across all TLS versions and MtE/EtM, and not something to
change lightly.

It appears twice so that we keep the entire "bits on wire" together, and
there's not (IMO) much incentive to try to justify deduplicating the two
locations of tls12_cid, since the incremental cost of MACing another byte
is pretty small.

> 2. Why should a "uint16 iv_length" be added?
> 2.a If it should be added, why as "uint16" instead of "uint8"
> 2.b If it should be added, why in the middle? It's not on the wire and
> so I would assume, if at all, to have that at the begin.

(Peter answered the "why have it at all" question.)

I think you are right that putting it before the "appears on wire" bits
makes a bit more sense.

I think it was uint16 out of chance/laziness, as I split the combined
"length of (IV + DTLSCiphertext.enc_content)" and just used the same width
of length field for both IV and enc_content.  Making it uint8 is probably
an improvement.

Thanks for taking a careful look,

Ben

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

[TLS] AD Evaluation of draft-ietf-tls-dtls13-39

[Benjamin Kaduk]

Hi all,

Sorry this took longer than planned to get to -- running my pubreq queue in
order took longer than expected.

I made a pull request with editorial/nit-level stuff at
https://github.com/tlswg/dtls13-spec/pull/160 (though some editorial
issues remain mentioned here where there is a lot of flexibility in how
to resolve them).

I think there are probably some DTLS-specific "implementation pitfalls"
that might merit a section akin to RFC 8446's Appendix C.3.

I also mention in the per-section comments a few places where we should
say a bit more about how we diverge from RFC 8446, and a few places
where being more explicit about separate read and write epochs would be
helpful.

Section 1

   1.2 (see Appendix D of [TLS13] for details).  While backwards
   compatibility with DTLS 1.0 is possible the use of DTLS 1.0 is not
   recommended as explained in Section 3.1.2 of RFC 7525 [RFC7525].

I guess we might want to reference draft-ietf-tls-oldversions-deprecate
by the time we hit the RFC Editor's queue.

Section 2

   -  connection: A transport-layer connection between two endpoints.

Can there even be a datagram "connection"?

Regardless, we should define "association" since we use that as well.

   -  handshake: An initial negotiation between client and server that
  establishes the parameters of their transactions.

This is the only place in the document where we use the word
"transaction", which makes me suspect that it is not the best word
choice.

   -  session: An association between a client and a server resulting
  from a handshake.

This seems technically true, but could be confusing if we want to have
an analogy DTLS Session:TLS Session::DTLS Association:TLS Connection.
(Per the previous comments, I am not 100% sure that we are trying to
have that anaolgy, though.)

Section 3.4

   DTLS optionally supports record replay detection.  The technique used
   is the same as in IPsec AH/ESP, by maintaining a bitmap window of

Do we want a reference for the IPsec usage?  (We do reference
https://tools.ietf.org/html/rfc4303#section-3.4.3 from §4.5.1 when we
talk about the mechanics of the replay window.)

   Applications may conceivably detect duplicate packets and accordingly
   modify their data transmission strategy.

The text here doesn't give me a clear impression of whether the
application is supposed to use the DTLS sequence numbers for this
detection, or their own (application layer) information.  (I didn't
think that most DTLS implementations exposed an API to give the
application the record sequence number.)

Section 4

   ProtocolVersion legacy_record_version;

We should probably say what value(s) are allowed here, akin to the RFC
8446 "MUST be set to 0x0303 for all records [...] other than an initial
ClientHello".

   Fixed Bits:  The three high bits of the first byte of the
  DTLSCiphertext header are set to 001.

Do we want to say something about why we have fixed bits and all and how
the values were chosen (perhaps a reference to RFC 7983)?

   If a connection ID is negotiated, then it MUST be contained in all
   datagrams.  Sending implementations MUST NOT mix records from
   multiple DTLS associations in the same datagram.  If the second or
   later record has a connection ID which does not correspond to the
   same association used for previous records, the rest of the datagram
   MUST be discarded.

I'm failing to come up with a reason why you would directly want to use
CIDs (for the same association) for records in a single datagram; should
we recommend using a single CID value per datagram explicitly?

   The entire header value shown in Figure 4 (but prior to record number
   encryption) is used as as the additional data value for the AEAD

Maybe forward-reference §4.2.3 for the record-number encryption?

   The entire header value shown in Figure 4 (but prior to record number
   encryption) is used as as the additional data value for the AEAD
   function.  For instance, if the minimal variant is used, the AAD is 2
   octets long.  Note that this design is different from the additional
   data calculation for DTLS 1.2 and for DTLS 1.2 with Connection ID.

In light of the ongoing discussion for the DTLS 1.2 connection ID, I
just want to walk through a few points here and confirm that we are in
good shape.

- (D)TLS 1.3 always requires AEAD ciphers
- AEAD ciphers implicitly authenticate the AAD length
- the connection ID is the only implicitly variable-length field in the
  record header/AAD (the size of the sequence number and length fields
  is indicated by bits in the first byte)
- in light of the above three points, the length of the connection ID is
  also implicitly authenticated by the AEAD
- the AAD explicitly flags whether or not a CID is present at all
- the AEAD implicitly authenticates the length of the ciphertext, so it
  is okay to omit the length from the AAD when the L bit is 0.

Section 4.1

   -  If the first byte is alert(21), handshake(22), or 

Re: [TLS] AD evaluation of draft-ietf-tls-ticketrequests-05

[Benjamin Kaduk]

Hi Chris, all,

This all sounds fine.  I'm happy to approve a manual posting during the
blackout period if we want to get this into IETF LC right away, though it's
probably fine to just wait for submissions to reopen, too.

Thanks,

Ben

On Thu, Nov 05, 2020 at 05:38:22AM -0800, Christopher Wood wrote:
> Thanks for the review, Ben! We addressed most of your comments here:
> 
>https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/22
> 
> Please see inline below for followup responses specific points. If there are 
> no objections, we'll spin a new version of the document when the submission 
> system opens.
> 
> On Wed, Oct 28, 2020, at 3:27 PM, Benjamin Kaduk wrote:
> > Section 2
> > 
> >*  Connection priming: In some systems, connections can be primed or
> >   bootstrapped by a centralized service or daemon for faster
> >   connection establishment.  Requesting tickets on demand allows
> >   such services to vend tickets to clients to use for accelerated
> >   handshakes with early data.  (Note that if early data is not
> >   needed by these connections, this method SHOULD NOT be used.
> >   Fresh handshakes SHOULD be performed instead.)
> > 
> > This doesn't seem to paint a very clear picture of the use case.  It
> > doesn't even seem to be clear about whether the "centralized service or
> > daemon" is a helper on the TLS client or server side!
> > I also want to check my understanding here, in that the recommendation
> > for only doing this when early data is needed is due to the fact that
> > you need to have an initial handshake with which to negotiate the
> > ability to use early data in the subsequent handshake, and having the
> > central service do a bunch of full handshakes just to get a ticket for
> > use on a subsequent connection that does user early data is a lot of
> > overhead, whereas if you don't need early data then you only do as many
> > full handshakes as you need connections (vs 2x that number to get a
> > ticket and then do early data) and get fully independent keys.  Since
> > you have this central service the extra latency for a full handshake is
> > irrelevant because you're priming connections in advance, not on-demand.
> 
> Describing this in more detail would lead to more text that probably just 
> distracts from the document. To keep things simple, we just deleted this 
> item, since there are plenty of motivating use cases already.
> 
> > 
> >*  Less ticket waste: Currently, TLS servers use application-
> >   specific, and often implementation-specific, logic to determine
> >   how many tickets to issue.  By moving the burden of ticket count
> >   to clients, servers do not generate wasteful tickets.  As an
> >   example, clients might only request one ticket during resumption.
> >   Moreover, as ticket generation might involve expensive
> >   computation, e.g., public key cryptographic operations, avoiding
> >   waste is desirable.
> > 
> > (I assume we have a particular case in mind that does use public-key
> > crypto when issuing a ticket, or we wouldn't have mentioned it.)
> 
> This just reflects the fact that ticket encryption is not required to be done 
> with a symmetric key. Servers are free to choose any type of encryption. (We 
> didn't change anything here.)
> 
> >When a client presenting a previously obtained ticket finds that the
> >server nevertheless negotiates a fresh session, the client SHOULD
> >assume that any other tickets associated with the same session as the
> >presented ticket are also no longer valid for resumption.  This
> > 
> > Unfortunately, RFC 8446 does not seem to be consistent about "session"
> > (persists across multiple resumption handshakes) vs "connection" (a
> > single handshake) terminology.  We may want to consider just discussing
> > "full handshake" and "initial full handshake" instead of trying to use
> > the "session" shorthand.
> 
> We converged on "connection" to avoid confusion, since that seems to be the 
> more natural term. 
> 
> >and the number requested.  Servers MAY send additional tickets, up to
> >the same limit, if the tickets that are originally sent are somehow
> >invalidated.
> > 
> > (nit) pedantically, the server can send whatever tickets it likes
> > whenever it likes.  The current "up to the same limit" looks a little
> > bit like it's trying to restrict the server's behavior, so "typically
> >

Re: [TLS] Intdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

[Benjamin Kaduk]

Hi Ted,

Thanks for the review, especially for thinking about the point that Éric
requested.

I don't really agree with your nit, though, as there have been improved
crypanalysis and correspondingly improved cryptographic attacks on both
algorithms over time (SHA1 more recently than MD5).  Increased
computational power to take advantage of those cryptographic weaknesses is
certainly a factor in moving to deprecate the vulnerable algorithms, but it
is not the only factor.

-Ben

On Wed, Oct 28, 2020 at 08:56:13AM -0700, Ted Lemon via Datatracker wrote:
> Reviewer: Ted Lemon
> Review result: Ready with Nits
> 
> This document is ready for publication, with one minor nit, which is included
> at the end.
> 
> Éric additionally made the following request:
>   As those hash algorithms were 'cheap' for TLS, I would appreciate a review 
> of
>   the impact if those algorithms are deprecated in TLS 1.2.
> 
> I am not in a position to do any practical tests, but I will point out several
> things. First, deprecating MD5 is not going to cause a performance problem
> because it's slower than SHA1, so we really only need to worry about whether
> deprecating SHA1 will cause a problem. This document only deprecates SHA1 for
> use in digital signatures. It "does not deprecate SHA-1 in HMAC for record
> protection." Given the way TLS uses digital signatures, this should not be a
> serious concern. At worst case, SHA256 is about 24% slower than SHA1. Best 
> case
> (shorter text) it is less than 16% slower. It's reasonable to expect that in
> common use in TLS, the texts being digested will be shorter, not longer.
> Further, the bulk of the computational burden of TLS is not in the generation
> of digests for digital signatures. Therefore it seems reasonable to expect 
> that
> the performance impact of this change is vastly overshadowed by one of the 
> very
> factors that motivates it: the increased speed of hash computation over time. 
> Even assuming constant speed legacy hardware, the performance impact is not
> sufficient to cause concern when considering it as part of the total system
> that would be using TLS 1.2.
> 
> Nit:
> 
> In the abstract:
>The MD5 and SHA-1 hashing algorithms are steadily weakening in
>strength and their deprecation process should begin for their use in
>TLS 1.2 digital signatures.
> 
> Technically, the strength of these algorithms hasn't changed. What's changed 
> is
> that their strength is no longer sufficient to prevent realistic attacks. So 
> it
> might be better to say something like "The vulnerability of MD5 and SHA-1
> algorithms to practical attacks is steadly increasing and ..."
> 
> 
> 

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

[TLS] AD evaluation of draft-ietf-tls-ticketrequests-05

[Benjamin Kaduk]

Hi all,

Thanks for everyone who contributed to this one; I think we ended up in
a pretty good place with it.  Sorry to have taken so long to get around
to processing it; on the plus side, the only document now in my
publication-requested queue is DTLS 1.3, and that will be entering AD
Evaluation shortly!

I think there's enough here that is reader-unfriendly that we should wait
to start the IETF LC until there's a new revision out, but hopefully the
needed changes will be fairly straightforward.

I made a few editorial suggestions and nit fixes at
https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/21 .

We have some level of duplication between the Introduction text
describing limitations of the stock 8446 mechanism, and the detailed use
cases in Section 2, but I think it's probably acceptable.

We talk about avoiding ticket reuse being a goal (e.g., explicitly so in
the "Parallel HTTP connections" use case), but we don't really say why.
I think the introduction could probably do with a paragraph on this that
references https://tools.ietf.org/html/rfc8446#appendix-C.4 for the
default behavior being to attempt to avoid reuse of tickets (without
implying that it is required behavior, of course).

Section 2

   *  Connection priming: In some systems, connections can be primed or
  bootstrapped by a centralized service or daemon for faster
  connection establishment.  Requesting tickets on demand allows
  such services to vend tickets to clients to use for accelerated
  handshakes with early data.  (Note that if early data is not
  needed by these connections, this method SHOULD NOT be used.
  Fresh handshakes SHOULD be performed instead.)

This doesn't seem to paint a very clear picture of the use case.  It
doesn't even seem to be clear about whether the "centralized service or
daemon" is a helper on the TLS client or server side!
I also want to check my understanding here, in that the recommendation
for only doing this when early data is needed is due to the fact that
you need to have an initial handshake with which to negotiate the
ability to use early data in the subsequent handshake, and having the
central service do a bunch of full handshakes just to get a ticket for
use on a subsequent connection that does user early data is a lot of
overhead, whereas if you don't need early data then you only do as many
full handshakes as you need connections (vs 2x that number to get a
ticket and then do early data) and get fully independent keys.  Since
you have this central service the extra latency for a full handshake is
irrelevant because you're priming connections in advance, not on-demand.

   *  Less ticket waste: Currently, TLS servers use application-
  specific, and often implementation-specific, logic to determine
  how many tickets to issue.  By moving the burden of ticket count
  to clients, servers do not generate wasteful tickets.  As an
  example, clients might only request one ticket during resumption.
  Moreover, as ticket generation might involve expensive
  computation, e.g., public key cryptographic operations, avoiding
  waste is desirable.

(I assume we have a particular case in mind that does use public-key
crypto when issuing a ticket, or we wouldn't have mentioned it.)

   When a client presenting a previously obtained ticket finds that the
   server nevertheless negotiates a fresh session, the client SHOULD
   assume that any other tickets associated with the same session as the
   presented ticket are also no longer valid for resumption.  This

Unfortunately, RFC 8446 does not seem to be consistent about "session"
(persists across multiple resumption handshakes) vs "connection" (a
single handshake) terminology.  We may want to consider just discussing
"full handshake" and "initial full handshake" instead of trying to use
the "session" shorthand.

   and the number requested.  Servers MAY send additional tickets, up to
   the same limit, if the tickets that are originally sent are somehow
   invalidated.

(nit) pedantically, the server can send whatever tickets it likes
whenever it likes.  The current "up to the same limit" looks a little
bit like it's trying to restrict the server's behavior, so "typically
using the same limit" might be better.

   Servers MUST NOT send the "ticket_request" extension in ServerHello
   or HelloRetryRequest messages.  A client MUST abort the connection
   with an "illegal_parameter" alert if the "ticket_request" extension
   is present in either of these messages.

I note that we do have other messages (Certificate, CertificateRequest,
NewSessionTicket itself, maybe soon ClientEncryptedExtensions) that can
carry extensions, so in that sense it's strange to only explicitly
prohibit these two.  That said, they are the two that would be most
tempting to (inadvertently) put this extension in, so I don't
particularly mind leaving it this way.

Section 6

I suppose there is perhaps some risk of traffic a

Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

[Benjamin Kaduk]

On Mon, Oct 26, 2020 at 06:07:07PM -0700, Eric Rescorla wrote:
> On Mon, Oct 26, 2020 at 6:00 PM Benjamin Kaduk  wrote:
> 
> > On Mon, Oct 26, 2020 at 05:38:33PM -0700, Eric Rescorla wrote:
> > > On Fri, Oct 23, 2020 at 7:13 PM Benjamin Kaduk  wrote:
> > >
> > > > Hi Ekr,
> > > >
> > > > Thanks for chiming in.
> > > >
> > > > On Thu, Oct 15, 2020 at 08:59:43AM -0700, Eric Rescorla wrote:
> > > > >
> > > > > - I agree with Ben that the current construction has some awkward
> > > > > properties and that prefixing the length field would remedy that.
> > It's
> > > > > been quite some time since we had this discussion but as I recall the
> > > > > rationale was to protect the bits on the wire as-is rather than some
> > > > > reconstructed version of them (see a number of long discussions on
> > > > > this topic), so just prefixing the CID length is also not ideal.
> > > >
> > > > I think the current scheme is unfortunately using fields put together
> > in a
> > > > rather different order than the actual bits on the wire (more below).
> > > >
> > >
> > > Right. I forgot that we also preserved the TLS order of the seqnum.
> > >
> > >
> > > > >
> > > > > This is a little goofy but it has (I think) the properties that (1)
> > the
> > > > > bytes appear
> > > > > in the MAC in the order they appear on the wire (2) fixed-length
> > metadata
> > > > > appears in
> > > > > the front (the seq_num already does) (3) the duplicated tls12_cid in
> > the
> > > > > front avoids confusion with MAC input for other records.
> > > >
> > > > I like (1) and (2) and agree with (3), though I'm having a little
> > trouble
> > > > lining up your figure with the DTLSCiphertext structure, which I'll
> > repeat
> > > > here so I'm not flipping back and forth as much:
> > > >
> > > > struct {
> > > > ContentType special_type = tls12_cid;
> > > > ProtocolVersion version;
> > > > uint16 epoch;
> > > > uint48 sequence_number;
> > > > opaque cid[cid_length];   // New field
> > > > uint16 length;
> > > > opaque enc_content[DTLSCiphertext.length];
> > > > } DTLSCiphertext;
> > > >
> > > > Ah, your proposal looks more natural if I compare it to the current
> > AEAD
> > > > "additional_data" from the -07:
> > > >
> > > > #  additional_data = seq_num +
> > > > #tls12_cid +
> > > > #DTLSCipherText.version +
> > > > #cid +
> > > > #cid_length +
> > > > #length_of_DTLSInnerPlaintext;
> > > >
> > > > If I could try to synthesize your key points (as I understand them),
> > hewing
> > > > more strictly to the "bits on the wire" philosophy would suggest
> > having us
> > > > use:
> > > >
> > > > additional_data:
> > > > struct {
> > > >   uint8 marker = tls12_cid;
> > > >   uint8 cid_len;
> > > >   uint8 content_type = tls12_cid;  \
> > > >   uint16 DTLSCiphertext.version;   |  appears on wire
> > > >   uint64 seq_num; // includes epoch|
> > > >   opaque cid[cid_len]; /
> > > >   uint16 length_of_DTLSInnerPlaintext;
> > > > };
> > > >
> > > >
> > > Mostly.
> > >
> > > I would expect the length here to not be DTLSInnerPlaintext but rather
> > the
> > > length field that appears on the wire, as in TLS 1.3. Do you agree with
> > > that? If not, let's discuss. If so, we can talk about the others.
> >
> > Good catch, the length on the wire makes more sense.  (I presume I just
> > cribbed from the -07 here and didn't think hard enough.
> >
> 
> So I think that the following is right for MtE.
> 
> struct {
>   uint8 marker = tls12_cid;
>   uint8 cid_len;
>   uint8 content_type = tls12_cid;  \
>   uint16 DTLSCiphertext.version;   |  appears on wire
>   uint64 seq_num; // includes epoch|
>   opaque cid[cid_l

Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

[Benjamin Kaduk]

On Mon, Oct 26, 2020 at 05:38:33PM -0700, Eric Rescorla wrote:
> On Fri, Oct 23, 2020 at 7:13 PM Benjamin Kaduk  wrote:
> 
> > Hi Ekr,
> >
> > Thanks for chiming in.
> >
> > On Thu, Oct 15, 2020 at 08:59:43AM -0700, Eric Rescorla wrote:
> > >
> > > - I agree with Ben that the current construction has some awkward
> > > properties and that prefixing the length field would remedy that. It's
> > > been quite some time since we had this discussion but as I recall the
> > > rationale was to protect the bits on the wire as-is rather than some
> > > reconstructed version of them (see a number of long discussions on
> > > this topic), so just prefixing the CID length is also not ideal.
> >
> > I think the current scheme is unfortunately using fields put together in a
> > rather different order than the actual bits on the wire (more below).
> >
> 
> Right. I forgot that we also preserved the TLS order of the seqnum.
> 
> 
> > >
> > > This is a little goofy but it has (I think) the properties that (1) the
> > > bytes appear
> > > in the MAC in the order they appear on the wire (2) fixed-length metadata
> > > appears in
> > > the front (the seq_num already does) (3) the duplicated tls12_cid in the
> > > front avoids confusion with MAC input for other records.
> >
> > I like (1) and (2) and agree with (3), though I'm having a little trouble
> > lining up your figure with the DTLSCiphertext structure, which I'll repeat
> > here so I'm not flipping back and forth as much:
> >
> > struct {
> > ContentType special_type = tls12_cid;
> > ProtocolVersion version;
> > uint16 epoch;
> > uint48 sequence_number;
> > opaque cid[cid_length];   // New field
> > uint16 length;
> > opaque enc_content[DTLSCiphertext.length];
> > } DTLSCiphertext;
> >
> > Ah, your proposal looks more natural if I compare it to the current AEAD
> > "additional_data" from the -07:
> >
> > #  additional_data = seq_num +
> > #tls12_cid +
> > #DTLSCipherText.version +
> > #cid +
> > #cid_length +
> > #length_of_DTLSInnerPlaintext;
> >
> > If I could try to synthesize your key points (as I understand them), hewing
> > more strictly to the "bits on the wire" philosophy would suggest having us
> > use:
> >
> > additional_data:
> > struct {
> >   uint8 marker = tls12_cid;
> >   uint8 cid_len;
> >   uint8 content_type = tls12_cid;  \
> >   uint16 DTLSCiphertext.version;   |  appears on wire
> >   uint64 seq_num; // includes epoch|
> >   opaque cid[cid_len]; /
> >   uint16 length_of_DTLSInnerPlaintext;
> > };
> >
> >
> Mostly.
> 
> I would expect the length here to not be DTLSInnerPlaintext but rather the
> length field that appears on the wire, as in TLS 1.3. Do you agree with
> that? If not, let's discuss. If so, we can talk about the others.

Good catch, the length on the wire makes more sense.  (I presume I just
cribbed from the -07 here and didn't think hard enough.)

-Ben

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

Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

[Benjamin Kaduk]

Hi Achim,

On Sat, Oct 24, 2020 at 08:56:08AM +0200, Achim Kraus wrote:
> Hi Ben,
> 
> >> Because each party sends the value in the "connection_id" extension
> >> it wants to receive as a CID in encrypted records, it is possible for
> >> an endpoint to use a globally constant length for such connection
> >> identifiers.  This can in turn ease parsing and connection lookup,
> >> for example by having the length in question be a compile-time
> >> constant.  Implementations, which want to use variable-length CIDs,
> >> are responsible for constructing the CID in such a way that its
> >> length can be determined on reception.  Such implementations must
> >> still be able to send CIDs of different length to other parties.
> >> Note that there is no CID length information included in the record
> >> itself.
> >
> > ...and thanks for the reminder about how we say so in the text already.
> 
> (your example from a previous e-mail)
> 
>  > Attempting to construct a trivial example on the fly, (hex)
> 
>  > 01 01 02 02 01 <513 bytes of plaintext content>
> 
>  > could be cid_length=1, cid=0x01, length_of_DTLSInnerPlaintext=0x0202,
>  > DTLSInnerPlaintext.content = 0x01 <513 bytes>, or it could be
>  > cid_length=2, cis=0x0101, length_of_DTLSInnerPlaintext=0x0201,
>  > DTLSInnerPlaintext.content = <513 bytes>.
> 
> I would feel much more comfortable, if you state,
> that you consider now either
> 
> 1. that example was not compliant to the draft,
> 
> or
> 
> 2. the draft is not clear enough about that.
> 
> If 1. is true, https://github.com/tlswg/dtls-conn-id/issues/76 could be
> closed.

It is neither of those two.

While the party that will be parsing packets that use a given CID value to
identify the connection needs to be able to determine the length from the
byte stream, the other party does not.  Accordingly, when computing the
MAC, there is still malleability in terms of which "interpretation" of the
byte stream was intended by the party computing the MAC.  The party
receiving the packet (and MAC) will only use one interpretation, but the
party generating the MAC could have been deceived into using the other
interpretation.

As I said previously, the CID values are not authenticated until the
handshake completes, so there is a real window where this attack surface is
exposed.  Note that I do not need to present a complete end-to-end attack
that breaks the TLS guarantees in order for us to change the spec -- it is
enough to have shown that the malleability of the cryptographic input
stream is exposed to potential attack.  To leave such behavior in a
published protocol spec would be irresponsible, in effect, publishing an
algorithm with known weaknesses.

Thanks,

Ben

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

Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

[Benjamin Kaduk]

Hi Ekr,

Thanks for chiming in.

On Thu, Oct 15, 2020 at 08:59:43AM -0700, Eric Rescorla wrote:
> I would like to make several points here:
> 
> - In terms of operational practice, in order for a server to
> function correctly, the CID must either be fixed-length for all
> clients that might need to be demuxed *or*
> self-describing. Otherwise, the server will not be able to determine
> the correct CID. I believe this is clear in the specification:

I am pretty sure that we all agree on this, yes...

>Because each party sends the value in the "connection_id" extension
>it wants to receive as a CID in encrypted records, it is possible for
>an endpoint to use a globally constant length for such connection
>identifiers.  This can in turn ease parsing and connection lookup,
>for example by having the length in question be a compile-time
>constant.  Implementations, which want to use variable-length CIDs,
>are responsible for constructing the CID in such a way that its
>length can be determined on reception.  Such implementations must
>still be able to send CIDs of different length to other parties.
>Note that there is no CID length information included in the record
>itself.

...and thanks for the reminder about how we say so in the text already.

> This is an important space optimization and in fact was one of the
> key points in getting us to variable CIDs in QUIC, so I would not
> want to take a regression here.
> 
> - I agree with Ben that the current construction has some awkward
> properties and that prefixing the length field would remedy that. It's
> been quite some time since we had this discussion but as I recall the
> rationale was to protect the bits on the wire as-is rather than some
> reconstructed version of them (see a number of long discussions on
> this topic), so just prefixing the CID length is also not ideal.

I think the current scheme is unfortunately using fields put together in a
rather different order than the actual bits on the wire (more below).

> - To the best of my knowledge, the ability to just disclose the
> encryption key but not the MAC key has never been part of the
> official interface of TLS -- and of course it doesn't really

I agree.

> work with many AEADs. So, anyone who is doing that is off the
> fairway and I don't think has any security guarantees (TLS aside,
> many application protocols have surprising security properties
> in this situation) With that said, we shouldn't break such uses
> unnecessarily, and it seems like there might be other negative
> side effects of the current construction.

To be clear, I'm more concerned about the "other negative side effects";
bringing up this case was just a convenient rhetorical device to attempt to
illustrate that what seems like a local cryptographic annoyance can be
parlayed into something more significant.

> So on balance, I think we should try to fix this. I'm slightly less
> enthusiastic about just swapping the length field, because I'd
> prefer to MAC the literal bytes (though perhaps we'll just have
> to live with that). However, it might be worth bikeshedding that
> some. Here's one potential alternative, though I haven't studied

Seeing you write this has served to finally hammer home for me a point that
Achim has been making for some time.  Sorry for being so dense about this,
Achim!  That is to say, if we're making any change at all, we should change
to what is unambiguously the Right Thing, not just make a fiddling change
on the margins -- there's not much difference in implementation impact, and
we can get it actually right and not have to change it again.

> struct {
>   uint8 marker = tls12_cid;
>   uint8 cid_len;
>   uint64 seq_num;
>   uint8 cid = tls12_cid;   \
>   uint16 DTLSCiphertext.version +  |  appears on wire   | non-CID MAC 
> input
>   opaque cid[cid_len]; /|
>   uint16 length_of_DTLSInnerPlaintext;  /
> }
> 
> This is a little goofy but it has (I think) the properties that (1) the
> bytes appear
> in the MAC in the order they appear on the wire (2) fixed-length metadata
> appears in
> the front (the seq_num already does) (3) the duplicated tls12_cid in the
> front avoids confusion with MAC input for other records.

I like (1) and (2) and agree with (3), though I'm having a little trouble
lining up your figure with the DTLSCiphertext structure, which I'll repeat
here so I'm not flipping back and forth as much:

struct {
ContentType special_type = tls12_cid;
ProtocolVersion version;
uint16 epoch;
uint48 sequence_number;
opaque cid[cid_length];   // New field
uint16 length;
opaque enc_content[DTLSCiphertext.length];
} DTLSCiphertext;

Ah, your proposal looks more natural if I compare it to the current AEAD
"additional_data" from the -07:

#  additional_data = seq_num +

Re: [TLS] [Last-Call] Last Call: (Deprecating MD5 and SHA-1 signature hashes in TLS 1.2) to Proposed Standard

[Benjamin Kaduk]

Hi Martin,

On Thu, Oct 15, 2020 at 11:56:05AM +0200, Martin Rex wrote:
> The IESG  wrote:
> > 
> > The IESG has received a request from the Transport Layer Security WG (tls) 
> > to
> > consider the following document: - 'Deprecating MD5 and SHA-1 signature
> > hashes in TLS 1.2'
> >
> >as Proposed Standard
> > 
> > The IESG plans to make a decision in the next few weeks, and solicits final
> > comments on this action. Please send substantive comments to the
> > last-c...@ietf.org mailing lists by 2020-10-28. Exceptionally, comments may
> > be sent to i...@ietf.org instead. In either case, please retain the 
> > beginning
> > of the Subject line to allow automated sorting.
> 
> 
> The new, backwards-incompatible and interop-fatal behaviour proposed in

"Backwards-incompatible" I can see, but "interop-fatal" seems yet to be
proven...

> section 2 of the current draft must be changed to reflect the updated
> rationale from section 6 of the very same document, and to promote
> safe and secure interoperability instead of a needless total interop failure.
> 
> Requesting interop failure where instead safe and secure interop can
> be easily obtained, as the current draft does, would be in serious
> violation of section 6 of RFC 2119 about where an imperative MUST
> is not allowed for the given situation.
> 
> 
> 
> Section 6 of the current draft says:
> 
>6.  Updates to RFC5246
> 
>[RFC5246], The Transport Layer Security (TLS) Protocol Version 1.2,
>suggests that implementations can assume support for MD5 and SHA-1 by
>their peer.  This update changes the suggestion to assume support for
>SHA-256 instead, due to MD5 and SHA-1 being deprecated.
> 
>In Section 7.4.1.4.1: the text should be revised from:
> 
>OLD:
> 
>"Note: this is a change from TLS 1.1 where there are no explicit
>rules, but as a practical matter one can assume that the peer
>supports MD5 and SHA- 1."
> 
>NEW:
> 
>"Note: This is a change from TLS 1.1 where there are no explicit
>rules, but as a practical matter one can assume that the peer
>supports SHA-256."
> 
> 
> and therefore the behaviour in section 2 about the "Signature Algorithms"
> extension ought to say:
> 
>2.  Signature Algorithms
> 
>Clients MUST NOT include MD5 and SHA-1 in the signature_algorithms
>extension.  If a client does not send a signature_algorithms
>extension, then the server MUST use (sha256,rsa) for
>digitally_signed on the ServerKeyExchange handshake message for
>TLS cipher suites using RSA authentication, and the server MUST use
>(sha256,ecdsa) for TLS cipher suites using ECDSA authentication.

... since your propsal here seems to be resulting in TLS servers
prior-to-this-RFC and TLS servers implementing this RFC using a different
interpretation for what the absence of a "signature_algorithms" extension
means.  That itself, seems like a recipe for interoperability failure,
absent some comprehensive case-by-case analysis showing that it is safe.
I, for one, will not support publication of a document including your
proposed change in the absence of such an analysis.

Furthermore, there is perhaps some awkward interaction between the way this
document refers to the contents of the "signature_algorithms" extensions
and the changes to that extension (and the corresponding IANA registry)
made by RFC 8446.  In the current state of the registry, there is not a
separate 'hash algorithm' field, and instead we must deal with combined
SignatureScheme codepoints.  One might argue that this document should
specifically enumerate the 16-bit SignatureScheme codepoints that are
prohibited.

(The SignatureScheme formulation also allows signature types other than RSA
and ECDSA, of course.)

>The server behaviour ought to be consistent for both, receipt of an
>extension-less SSLv3+ ClientHello handshake message, and for a
>backwards-compatible SSL VERSION 2 CLIENT-HELLO (which can not convey
>any TLS extensions) as described in Appendix-E.2 of rfc5246,
>and as permitted in bullet 2 in section 3 of RFC6176.

I note that we prohibited SSLv2-compatible ClientHello for TLS 1.3
implementations.  If we are to assume the current formulation of the draft
where absence of the "signature_algorithms" extension continues to imply
inferred support for SHA-1 and MD5, which are now forbidden, then it is a
natural consequence that the SSLv2-compatible ClientHello cannot
successfully negotiate a handshake, and is de facto forbidden.  I am not
entirely sure why you feel there is a need in the ecosystem to continue to
support the SSLv2-compatible ClientHello; do you, perhaps, know of some
implementation that cannot generate an SSLv3/TLS ClientHello but would
otherwise interoperate (using your formulation where no
"signature_algorithms" means inferred SHA-256 support) with a server that
adheres to this draft's strictures?

> 
> 
> As desribed in RFC6151, collision attacks on MD5 were appearing in
> p

Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

[Benjamin Kaduk]

On Tue, Oct 13, 2020 at 06:41:50AM +0200, Achim Kraus wrote:
> Hi Ben,
> 
> >
> >> Just as forecast:
> >> Without agreement, that the CIDs must be encoded using deterministic
> >> interpretation, which in my opinion obsoletes these "number games",
> >> next Summer either Raccoon or Kenny will write up their next
> >> "time side channel attack" on this.
> >> (The ambiguity will end up in try out the MAC for both "different
> >> MAC_write_key" and so create a time signal. Or with "same MAC_write_key"
> >> the receiver will not know by the failing MAC, which interpretation is
> >> the right. I guess, this will end up in decrypt twice, also obvious time
> >> signal.)
> >
> > Just to check my understanding: your forecast of an attack is predicated on
> > implementations that accept both potential MAC calculations proposed (CID
> > length before CID and CID length after CID)?  I do not think we should
> > allow things to progress to a state where accepting both forms is
> > encouraged, precisely because it leads to this sort of difficulty.   Hence,
> > my suggestion to assign a different extension codepoint, so an
> > implementation knows exactly which procedure to use.
> >
> 
> My concerns are based on permit ambiguous CIDs.

Ah, I think I understand better now (based on this and the rest of your
note).  I do not think we should allow such ambiguous CIDs, since (as you
note) they would require some "trial decryption" processing and the ensuing
time channels.  That said...

>  > Attempting to construct a trivial example on the fly, (hex)
> 
>  > 01 01 02 02 01 <513 bytes of plaintext content>
> 
>  > could be cid_length=1, cid=0x01, length_of_DTLSInnerPlaintext=0x0202,
>  > DTLSInnerPlaintext.content = 0x01 <513 bytes>, or it could be
>  > cid_length=2, cis=0x0101, length_of_DTLSInnerPlaintext=0x0201,
>  > DTLSInnerPlaintext.content = <513 bytes>.
> 
> That results in my opinion in cid 01 and cid 01 01 being valid for the
> same peer and same time.

The attack does not require that both are valid for the same peer at the
same time -- the attack can still occur when the party producing the MAC is
induced to use the "wrong" (invalid CID) interpretation of the byte stream
but then the version with valid CID is presented to the party verifying the
MAC.  If the internal structure (including length encoding) of the CID is
opaque to the party producing the MAC, that party cannot validate the data
used as input to the MAC.

(Sorry for duplicating this previous paragraph here and on the github
issue.)

-Ben

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

Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

[Benjamin Kaduk]

On Tue, Oct 13, 2020 at 06:50:52AM +0200, Achim Kraus wrote:
> Hi Ben,
> 
> > Sure, there's pretty standard common-knowledge guidance, though I'm not
> > sure it's documented anyplace particularly discoverable:
> >
> > - include in the MAC as much application/protocol context and protocol
> >fields as you can without breaking operation of the procotol
> > - ensure that the mapping from (set of protocol fields and values derived
> >from application context) to (bytes given as input to the MAC function) 
> > is
> >an injective mapping
> >
> > In some (many?) cases, there is not any additional contextual information
> > available, and the protocol header itself has a deterministic/fixed-length
> > encoding, so both points can be achieved by just using the protocol
> > header/payload as it appears on the wire as MAC input.  For better or for
> > worse, the current construction in the -07 diverges significantly from the
> > actual protocol header, so we have to do a bit of thinking to ensure that
> > we are compliant to the guidelines (that I just described, so I assume you
> > did not previously think about them in that formulation).
> >
> 
> Hope, I'm not again catched by my bad english :-):

Sorry, my writing became less clear when I attempted to edit it :(

> If the forumlation refers to draft-ietf-tls-dtls-connection-id-07 (and
> not my e-mails), I can't say, what was thought or not by the authors. My
> role in that discussion quite a year ago, was just to ask, which of the
> many variants should then be chosen in order not to change it every year.

I was just saying "I only told you the list of two things that are the
standard guidance just now; I don't expect that you used those two things
as part of your thought processes before I told them to you".

-Ben

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

Re: [TLS] AD review of draft-ietf-tls-oldversions-deprecate-06

[Benjamin Kaduk]

Hi Mike,

On Tue, Oct 13, 2020 at 03:59:27PM -0400, Michael D'Errico wrote:
> > Saying that it's your preference without saying why is likely
> > to have little effect, yes.  (We endeavor to make decisions
> > based on technical merit, not voting, after all.)  Why do you
> > want this?
> 
> Hi,
> 
> I think the advice should be: "If your code currently
> only supports TLS 1.0, please spend a week or two
> adding support for both TLS 1.1 and the downgrade
> protection SCSV."
> 
> Since the vast majority of the 1.0 and 1.1 specifications
> is the same, someone who takes the advice has a
> good chance of succeeding.
> 
> (You could then also say which other extensions are
> important and why, roughly in order of importance.)

I don't see much to object to in that advice, but the precondition is
rather limiting.  Have you considered writing a draft that covers it
(including fleshing out the important extensions)?

> Recommending that people wholesale abandon
> their legacy system and implement TLS (1.2 and)
> 1.3 is asking too much, and will largely be ignored
> by the people who would be able to add 1.1 to their
> 1.0 code.

It may be true that such recommendations will largely be ignored by people
who have 1.0-only implementations (recall that the IETF does not have an
enforcement arm!), but draft-ietf-tls-oldversions-deprecate aims to be a
Best Current Practice, and there are not preconditions to that Best.  The
Best thing you can do for TLS involves TLS 1.3, and TLS 1.2 is probably
okay, too.  I don't see anyone arguing that the Best Curent Practice for
TLS, in general, involves TLS 1.0 or 1.1, at this point.

-Ben

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

Re: [TLS] AD review of draft-ietf-tls-oldversions-deprecate-06

[Benjamin Kaduk]

Hi Mike,

On Tue, Oct 13, 2020 at 03:09:15PM -0400, Michael D'Errico wrote:
> I know that saying this will have no effect, but I'd
> rather see deprecation of just TLS 1.0 and retain
> version 1.1 as not recommended.

Saying that it's your preference without saying why is likely to have
little effect, yes.  (We endeavor to make decisions based on technical
merit, not voting, after all.)  Why do you want this?  TLS 1.1 seems to
have minimal usage (less even than 1.0) and is much closer to 1.0 than 1.2
(let alone 1.3) in terms of design and safety.

> Also, we should not abandon RFC 7507 (downgrade
> protection SCSV).  What harm is there in keeping it
> around?  None.

I don't expect implementations to abandon SCSV any faster than they abandon
TLS 1.0 or 1.1.  But if the official advice is that 1.0 and 1.1 are
obsolete, then the official advice should also be that SCSV is obsolete --
its function is performed in a different way by the newer versions of TLS.

-Ben

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

Re: [TLS] AD review of draft-ietf-tls-oldversions-deprecate-06

[Benjamin Kaduk]

Thanks, Sean, the linked pull requests seem to do the trick.

Skimming through
https://mailarchive.ietf.org/arch/msg/tls/K9_uA6m0dD_oQCw-5kAbha-Kq5M/ once
more, I think I still plan to put out a status-change document to move RFC
5469 (IDEA and DES ciphers) to Historic in parallel with the IETF LC for
this document.  It is probably not critical that we mention such a change
in the document text, though we could if we want to.

I think we still need to check for the latest version of the SP800-52r2
reference, too.

Thanks again,

Ben

On Tue, Oct 13, 2020 at 01:02:07PM -0400, Sean Turner wrote:
> Ben,
> 
> Thanks for pointing out I missed a couple. Inline …
> 
> spt
> 
> > On Aug 13, 2020, at 13:54, Benjamin Kaduk  wrote:
> > 
> > Hi Kathleen,
> > 
> > Also inline.
> > 
> > On Wed, Aug 12, 2020 at 04:29:56PM -0400, Kathleen Moriarty wrote:
> >> Hi Ben,
> >> 
> >> Thanks for your review.  Some initial responses are inline.
> >> 
> >> On Sun, Jul 26, 2020 at 5:22 PM Benjamin Kaduk  wrote:
> >> 
> >>> I found three documents (3656, 4540, 7562) in the list of update targets
> >>> that are on the ISE (not IETF) stream.  I had talked to Adrian during my
> >>> preliminary review, and in principle it is permissible to make those
> >>> updates as part of this document, but we will need specific ISE approval
> >>> to do so.  I am supposed to sync up with him during IETF LC, but the
> >>> document needs to be updated to clarify that the updates of ISE
> >>> documents are/will be done with permission of the ISE.  (Please also try
> >>> to double-check that the list is complete; I didn't find an
> >>> authoritative list of "all documents on the ISE stream" to grep against,
> >>> and I didn't try to have something parse rfc-index.xml to output such a
> >>> list.
> >>> 
> >> 
> >> OK, so you'd like a list added and that's not in your pull request, is that
> >> right?  We'll figure it out. Thanks in advance with the coordination with
> >> Adrian.
> > 
> > That's correct, this is not in my pull request (not least because that list
> > of three documents is incomplete -- I sent a more-likely-complete list of 6
> > documents in an off-list follow-up.
> > https://www.rfc-editor.org/search/rfc_search_detail.php?stream_name=Independent&page=All
> > will get a (presumably authoritative) list of ISE-stream documents, FWIW.
> 
> After going through the list I found six. Here’s some text that addresses the 
> fact that will have permission from the ISE:
> https://github.com/tlswg/oldversions-deprecate/pull/6
> 
> >>> Section 1.1
> >>> 
> >>> I went through all 83 of the references in the big list, that are
> >>> supposed to be ones that "normatively reference TLS 1.0/1.1 or DTLS 1.0,
> >>> as well as the shorter list of already-obsoleted documents.
> >>> 
> >>> I won't bore you with my full notes, but there are some particular
> >>> things that stood out from the review:
> >>> 
> >>> - We have a separate list of updates for documents that are already
> >>>  obsolete (but don't say much about why we're going go the extra
> >>>  bother).  However, three of the documents in our main list of updates
> >>>  (4743, 4744, and 6460) are already Historic, and presumably should be
> >>>  treated more like the already-obsolete ones.
> >>> 
> >> 
> >> Obsolete does not mean the same thing as deprecate though.  TLSv1.2 has
> >> been obsoleted by TLSv1.3, but not deprecated.  The deprecation goes the
> >> extra step to say not to use it and it triggers many to begin phase out
> >> plans.  Am I misunderstanding the question?
> > 
> > I think you're misunderstanding the question, yes, sorry.
> > 
> > I think we want the documents that are Historic to be listed separately
> > from the other ("regular") updates, in a manner akin to what is already
> > done for the documents that are currently obsolete.  Or, perhaps, to say
> > that there is no point in deprecating something that is already historic,
> > and not bother updating those three documents, but it seems okay to keep
> > the current status with a comprehensive list of updates.
> 
> How about this:
> https://github.com/tlswg/oldversions-deprecate/pull/7
> 
> spt
> 
> 

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

Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

[Benjamin Kaduk]

On Sat, Oct 10, 2020 at 09:13:51AM +0200, Achim Kraus wrote:
> Hi Ben,
> 
> >
> > To be frank, I'm actually surprised that this is even seen as a matter for
> > discussion.
> 
> As developer, I'm surprised, that this discussion now spans a couple of
> years, starting on summer 2018 with:
> 
> https://github.com/tlswg/dtls-conn-id/issues/8

Well, we are not always happy about it (in fact, usually are unhappy), but
writing protocol specifications does have a reputation for taking a long
time due to repeated experiences.  It's also the case that the spec isn't
done until it's done, and that breaking changes to the spec are possible at
any time before it's done.

> There are many (proposed) changes since then. I already tried to point
> to that with my e-mail answer from 4. September
> 
>  >> That order was also discussed a lot.
>  >> https://github.com/tlswg/dtls-conn-id/pull/29
>  >> I would prefer, if this is not changed again without strong arguments!
> 
> For me, "cryptographic hygiene", which breaks the API, are not strong
> arguments. Sure, that's only my personal opinion. I'm not sure, if a new
> code-point helps, nor that a new one is emitted for changing a draft (I
> would not recommend to do so, draft is a draft).

A codepoint should have a specific well-defined behavior.  The current
allocation of extension type 53 is explicitly marked as TEMPORARY and
can+will age out if we get a new one for the new semantics; this is normal.

> So let me try to find a end:
> As developer, I see it's very important to come to a stable definition
> of the MAC. If now the order of the cid/cid-length is changing the MAC
> (again), and in half a year the next "cryptographic hygiene" campaign
> removes the cid-length (because it's not on the header and some
> (including me) don't see the benefit), then FMPOV this "process" just
> demonstrates more weakness, than I appreciate.
> 
> So:
> If there is a guideline for constructing MACs, is that guideline
> documented somewhere?
> If the guideline is changing over the time, are these changes documented?

Sure, there's pretty standard common-knowledge guidance, though I'm not
sure it's documented anyplace particularly discoverable:

- include in the MAC as much application/protocol context and protocol
  fields as you can without breaking operation of the procotol
- ensure that the mapping from (set of protocol fields and values derived
  from application context) to (bytes given as input to the MAC function) is
  an injective mapping

In some (many?) cases, there is not any additional contextual information
available, and the protocol header itself has a deterministic/fixed-length
encoding, so both points can be achieved by just using the protocol
header/payload as it appears on the wire as MAC input.  For better or for
worse, the current construction in the -07 diverges significantly from the
actual protocol header, so we have to do a bit of thinking to ensure that
we are compliant to the guidelines (that I just described, so I assume you
did not previously think about them in that formulation).


For what it's worth, I am in a similar position as you in that I don't see
a specific reason that including the CID length explicitly is *required*,
since the CID itself would need to be using a self-delineating encoding in
order for the packet to be parseable (if variable-length CIDs are used at
all; a fixed-length CID is trivially delineated).  I would be pretty okay
with not having the separate length field if our MAC inputs more closely
followed the record header (and, to be honest, I could accept not having it
at all even with the current order of (other) fields in the MAC input, in
the absence of specific reasoning why it's needed), though I prefer to keep
an explicit length if we stay with something resembling the current
formulation (that diverging from the record header as it appears on the
wire), just to make it easier to reason about.  I still, however, object to
the construction in the -07 that puts the CID length after the CID -- there
is no point in having the CID length if you need a self-delineating CID
anyway [1], and its current location gives an aveue of malleability to an
attacker.  Leaving this kind of local malleability of MAC input in place
seems irresponsible and is not in keeping with the quality expectations for
the output of the TLS working group.

(We should also check to make sure that we properly document the
requirements on CID generation and parsing schemes, as you noted
elsewhere.)

> And I would really welcome, also based on the experience with the long
> history of this discussion, if more can give their feedback about
> changing the MAC again. Please, this year, not next :-).

I believe that Joe's response supports my "don't leave areas of local
malleability in place" stance.  I guess maybe the discussion is migrating
to the github issue, though, so I will try to watch there as well.

Thanks,

Ben

[1] "need [...] anyway" here is perhaps most u

Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

[Benjamin Kaduk]

Hi Achim,

On Sun, Oct 11, 2020 at 07:43:14PM +0200, Achim Kraus wrote:
> Hi Watson,
> 
> > The doubt is because of where it appears not that it appears. If every
> > value was preceded by its length the encoding would obviously be
> > injective.
> 
> I hope, this is just a "typo" or "mistake".
> 
> Prepending the length is the change, Ben want to use to protect against
> injection. You now say, this will be "obviously injective".

Since apparently this was not fully clear, allow me to link the wikipedia
article corresponding to "injective map (in the mathematical sense)" in my
earlier description: https://en.wikipedia.org/wiki/Injective_function

> > Here though it isn't clear if two different inputs to the
> > encoding could end up the same.
> 
> Though the MAC definition starts with "MAC_write_key", I'm pretty sure,
> all examples so far are just incomplete. They must declare, if the
> "different/ambiguous" CIDs are refer to the same "MAC_write_key" or not.
> 
> "different MAC_write_key" => obviously "end up" different.
> "same MAC_write_key" => the decoding of the records gets ambiguous
> 
> > In fact I think in the MAC setting
> > there almost certainly is a problem as the length of the ciphertext is
> > right after the cid length, and with some cleverness you can come up
> > with a cid and ciphertext that could be interpreted multiple ways.
> > Unfortunately I haven't followed the draft's discussions that closely.
> >
> > I do not understand how a CID is supposed to be parsed by a recipient
> > when the length can change and the length field is not encoded, but
> > perhaps I'm misreading the intent of the [] notation in the record
> > layer of the draft.
> 
> That's just a theroretical numbers game. No one os far made any really
> useful example from start to end. FMPOV, "CID with dynamic length" MUST

In my opinion a useful example from start to end is not a prerequisite for
making a change to the spec in the face of a demonstrated local weakness.
Attacks only ever get better, and we should not leave known building blocks
for them in place.

> use a unique/deterministic encoding. If that encoding ambiguous, as
> others imply/assume in their "numbers game", the whole record gets
> ambiguous.

Yes, an entity assigning its own CIDs has to be able to distinguish them on
receipt based on the record bitstream (which does not supply its own
framing for the CID length).  The current text may not be as explicit about
this requirement as it could be (it may only list a requirement that the
values given out have to be recognized, not that there has to be a unique
parsing of all potential CID bytestreams in a received record that rejects
invalid ones?  I didn't check).

> Just as forecast:
> Without agreement, that the CIDs must be encoded using deterministic
> interpretation, which in my opinion obsoletes these "number games",
> next Summer either Raccoon or Kenny will write up their next
> "time side channel attack" on this.
> (The ambiguity will end up in try out the MAC for both "different
> MAC_write_key" and so create a time signal. Or with "same MAC_write_key"
> the receiver will not know by the failing MAC, which interpretation is
> the right. I guess, this will end up in decrypt twice, also obvious time
> signal.)

Just to check my understanding: your forecast of an attack is predicated on
implementations that accept both potential MAC calculations proposed (CID
length before CID and CID length after CID)?  I do not think we should
allow things to progress to a state where accepting both forms is
encouraged, precisely because it leads to this sort of difficulty.   Hence,
my suggestion to assign a different extension codepoint, so an
implementation knows exactly which procedure to use.

-Ben

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

Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

[Benjamin Kaduk]

Hi Mike,

On Sat, Oct 10, 2020 at 01:29:13PM -0400, Michael D'Errico wrote:
> On Fri, Oct 9, 2020, at 17:22, Benjamin Kaduk wrote:
> > [...]  The behavior we should demand from our cryptographic
> > constructions is that the cryptography itself correctly returns
> > "valid" or "invalid" based on the input message, provided that
> > the application inputs the correct key material.  (It should also
> > return "invalid" if incorrect key material is supplied, of course.)
> > The ability to produce two different messages for which the
> > cryptography returns "valid" violates this principle; even if we
> > do not see an obvious path by which a reasonable application
> > might supply those inputs to the cryptographic code, it is still
> > a flawed construction.
> 
> Hi,
> 
> I'd like clarification about this point, where the cryptography
> should return values of "valid" or "invalid".  This is a general
> question, not specifically about this draft.  (Please read at
> least the next 2 paragraphs.)
> 
> I remember a long time ago, it may have been the renegotiation
> info extension, where there was a lot of calculation being done,
> there were two complicated values each side had to compute.
> If they were equal, then everything was fine and the handshake
> could proceed.  If not, there was an insecure renegotiation
> happening.  (Or maybe it was the downgrade protection RFC,
> I can't remember now.)  But if the values were not equal, then
> something bad was happening and the handshake should not
> proceed.
> 
> The problem both Martin Rex and I discovered at nearly the
> same time (posts to the mailing list within minutes of each
> other) was that both sides could go through all the motions
> faithfully calculating all of the values, correctly, and then
> forget to compare them to see if the values were actually
> the same.  I noticed this because I wrote the code, and it
> seemed like an easy thing to overlook.
> 
> I remember suggesting that we somehow incorporate the
> calculated values into the derivation of the record layer keys
> so the MAC would fail, or maybe into the Finished message
> calculation so (if you remember to check that?) a failure is
> noticed later.  This suggestion was shot down by the author
> unilaterally for what I perceived at the time to be petty
> reasons.
> 
> I still believe that (D)TLS security should not rely on the
> implementer to check whether two values are equal.  This
> is too easy to forget to do.  Or you could do this in C:
> 
> if (complex_value_a = complex_value_b) {
> // we're in trouble
> }
> 
> I have not looked at the TLS 1.3 draft beyond the hour or so
> I've put in so far to see whether this reliance on checking is
> in there too.  I've also not checked whether the security

The TLS 1.3 handshake transcript is an input to the key schedule; manual
comparison of generated values is not necessary for security.

I would encourage you to continue in your efforts reading RFC 8446 -- in my
opinion we put quite a bit of effort in towards making it readable.  (With,
perhaps, the exception of stateless HelloRetryRequest as you have already
noted, since the main expected use case is in DTLS.)

-Ben

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

Re: [TLS] Hybrid key exchange in TLS 1.3 and variable-length secrets

[Benjamin Kaduk]

Might as well publish a new revision of the I-D in the datatracker, too, since
the current one is approaching its expiry.

-Ben

On Fri, Sep 25, 2020 at 10:16:01AM -0400, Douglas Stebila wrote:
> Thanks!  I've merged it in.
> 
> On Fri, Sep 25, 2020 at 4:48 AM Nimrod Aviram  wrote:
> >
> > Thanks!
> > The PR is here, happy to hear comments and corrections:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_dstebila_draft-2Dietf-2Dtls-2Dhybrid-2Ddesign_pull_1&d=DwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=scN8KVeFpWVHjq0xefZ-MgaFkz3Dur3X0b6_ev41lZE&s=uEgApPwG25neG5tcewrPfJxk6KO-9aot8ZysgPeA-Bw&e=
> >  
> >
> > best,
> > Nimrod
> >
> >
> > On Fri, 18 Sep 2020 at 12:04, Nimrod Aviram  wrote:
> >>
> >> Sounds good to me.
> >> I'm happy to send a PR making these changes, but couldn't find the 
> >> repository for the document.
> >> Could you please point me to it?

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

Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

[Benjamin Kaduk]

Hi Achim,

On Fri, Oct 09, 2020 at 07:56:00AM +0200, Achim Kraus wrote:
> Hi Ben,
> 
>  >> If that is going to be changed, the early adopters run into trouble with
>  >> their deployments!
>  >
>  > I'm not sure I follow.  Are you saying that if there is a theoretical
>  > problem with the construction it would have been exposed by
> implementation
>  > testing?
> 
> No, I don't say that.
> "Early adopters" means, there people using
> draft-ietf-tls-dtls-connection-id-07 in real world systems with that
> current definiton of the MAC. If that MAC calculation is changed, then
> they need to adapt their deployments in the field, which is not too easy
> (and potential dangerous). Sure, draft-ietf-tls-dtls-connection-id-07 is
> still only a draft and could be changed. But not without trouble for
> those "early adopters".

Ah, I see what you mean now.

If we are concerned about changing the behavior, we can (and, arguably,
should) allocate a new TLS extension codepoint to indicate the new
behavior.  That would leave existing implementations able to function with
the old semantics until they age out/are upgraded/etc.

>  > My primary concern is not actually about a specific situation where
>  > injection occurs, but rather for cryptographic hygiene -- whenever we
>  > assemble an input for a cryptographic operation (especially MAC or
> signing)
>  > it is important to ensure that the sequence of bits used as input to the
>  > cryptographic operation can only be produced by a single combination of
>  > logical inputs to the protocol-level operation or message that we are
>  > applying cryptographic protection to.  This property is known as
>  > "injectivity", because the map from protocol-level values to bitstrings
>  > (themselves used as input for cryptographic operations) is an injective
>  > mapping in the mathematical sense.  I believe that I have
> demonstrated that
>  > the current MAC construction does not use an injective mapping and is
> thus
>  > not consistent with best practices.
> 
> *** protocol-level operation or message ***
> 
> I understood your example in your previous mail.
> I tried to explain, that the data of your example, especially the
> cid-length, is not in the message. Please, find the time to check that
> current record defintion! There the CID is encoded in the protocols
> tls-cid-records without the explicit CID length.

I understood your previous message, as well -- yes, the CID length is not
encoded in the message on the wire, and is implicit based on what the
entity allocating it has advertised.  I am asserting that the cryptographic
construction we are using is flawed, which is independent of what is
actually on the wire.

To be frank, I'm actually surprised that this is even seen as a matter for
discussion.  We've been doing quite well recently (e.g., for TLS 1.3) at
using rigorous and veriviable cryptographic constructions that are provably
secure at the smallest modular level.  This scheme is a regression in that
regard -- it relies not only on the cryptography for secure operation, but
also on some specific behavior of the application that is external to the
cryptographic processing (relating to how the application extracts the CID
and looks up the DTLS association/key material).  The behavior we should
demand from our cryptographic constructions is that the cryptography itself
correctly returns "valid" or "invalid" based on the input message, provided
that the application inputs the correct key material.  (It should also
return "invalid" if incorrect key material is supplied, of course.)  The
ability to produce two different messages for which the cryptography
returns "valid" violates this principle; even if we do not see an obvious
path by which a reasonable application might supply those inputs to the
cryptographic code, it is still a flawed construction.

-Ben

> With that, I can't see the posssiblity to inject the cid-length.
> It's simply not "in" and so can't be "injected".
> 
> best regards
> Achim Kraus
> 
> Am 09.10.20 um 01:34 schrieb Benjamin Kaduk:
> > Hi Achim,
> >
> > Sorry for the long silence on this front; my attention had cycled elsewhere
> > and I was just overall operating slowly for a couple weeks (sick, maybe,
> > but no clear symptoms).
> >
> > My primary concern is not actually about a specific situation where
> > injection occurs, but rather for cryptographic hygiene -- whenever we
> > assemble an input for a cryptographic operation (especially MAC or signing)
> > it is important to ensure that the sequence of bits used as input to the
> > cryptographic operati

Re: [TLS] AD review of draft-ietf-tls-dtls-connection-id-07

[Benjamin Kaduk]

Hi Achim,

Sorry again for the delayed response.  (Inline.)

On Fri, Sep 18, 2020 at 09:59:55AM +0200, Achim Kraus wrote:
> Hi Ben,
> 
> 
> Am 16.09.20 um 08:31 schrieb Achim Kraus:
> > Hi Ben,
> >
> >>>
> >>> If I did't get it, it may be easier to discus this as issue in the
> >>> github repo.
> >>
> >> I think you got it; I am just failing to remember where the "MUST anyway
> >> use new handshakes" requirement comes in from.  And I guess that also
> >> raises the question of what the expected behavior is when a server
> >> expects
> >> CID-ful traffic on a given 5-tuple and receives an (unencrypted)
> >> ClientHello on that 5-tuple.
> >>
> >
> > "when a server expects CID-ful traffic on a given 5-tuple"
> >
> > I'm not sure, why that should happen. If CID is used, the server should
> > not expect a given 5-tuple (at least not longer than a few seconds).
> > If a new CLIENT_HELLO arrives, it's first challenge it with a
> > HELLO_VERIFY_REQUEST. If that verification succeeds and a "old 5-tuple
> > of a previous CID message" is hit, then just mark/remove the 5-tuple of
> > that CID association. That mainly means, you will not be able to reach
> > the CID peer with that 5-tuple. That's anyway extremely common to lose
> > the ip-route to such CID peers, otherwise CID would not be required.
> >
> 
> Let me add:
> 
> - If the scenario uses "dynamic 5-tuples, with CID or without" and
> "static 5-tuples without CID",
> - then an attack, with the spoofed 5-tuple (out of that static-5-tuple"
> pool) and CID (described in
> https://github.com/tlswg/dtls-conn-id/issues/64), may disrupt the
> communication to such a static-5-tuple without CID.

Yes, I think this is the disruption I was pondering.

> Even then, that "static-5-tuple" peers must be anyway aware, that
> sometimes new handshakes are required. So that scenario may also depend
> more on the volume of such attacks, than just on the pure possibility.

It does seem like a pretty rare/difficult attack, unlikely to be worth the
trouble.  But perhaps it is still worht documenting as a property of the
protocol ...

> In my experience, such "static-5-tuples" are rare and I would guess,
> they will benefit from different handling also for other reasons.
> Therefore I would just spend them an separate endpoint to separate their
> traffic.

... especially when we can give this recommendation as a workaround.
(Actually, is it generally a good idea to try to steer CID-ful and CID-less
traffic to different endpoints?)

Thanks,

Ben

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

Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

[Benjamin Kaduk]

Hi Achim,

Sorry for the long silence on this front; my attention had cycled elsewhere
and I was just overall operating slowly for a couple weeks (sick, maybe,
but no clear symptoms).

My primary concern is not actually about a specific situation where
injection occurs, but rather for cryptographic hygiene -- whenever we
assemble an input for a cryptographic operation (especially MAC or signing)
it is important to ensure that the sequence of bits used as input to the
cryptographic operation can only be produced by a single combination of
logical inputs to the protocol-level operation or message that we are
applying cryptographic protection to.  This property is known as
"injectivity", because the map from protocol-level values to bitstrings
(themselves used as input for cryptographic operations) is an injective
mapping in the mathematical sense.  I believe that I have demonstrated that
the current MAC construction does not use an injective mapping and is thus
not consistent with best practices.

However, in particular...

On Sun, Oct 04, 2020 at 04:35:49PM +0200, Achim Kraus wrote:
> Hi Ben,
> 
> any progress on the cid-length / calculate MAC topic?
> 
> As I wrote, though the cid-length itself is not "on the wire" (it's only
> the cid), I can't see, that the cid-length could be injected.
> Do I oversee soemthing?
> 
> best regrads
> Achim Kraus
> 
>  Weitergeleitete Nachricht 
> Betreff: Re: [TLS] AD review of draft-ietf-tls-dtls-connection-id-07
> Datum: Wed, 16 Sep 2020 08:31:19 +0200
> Von: Achim Kraus 
> An: Benjamin Kaduk 
> Kopie (CC): draft-ietf-tls-dtls-connection...@ietf.org, tls@ietf.org
> 
> Hi Ben,
> 
> ...
> 
> >>>
> >>> The TLS 1.2 notation is "seq_num" for the implicit sequence number, but
> >>> DTLS 1.2 says that the MAC input is the concatenation of the DTLS epoch
> >>> and the DTLS (explicit) sequence number.  I do not see this
> >>> concatenation given the name "seq_num" anywhere, so I think we need to
> >>> reformulate this expression.
> >>>
> >>>  cid +
> >>>  cid_length +
> >>>
> >>> Does this construction preserve injectivity?  It seems easier to reason
> >>> about when the length of an element is always before or always after the
> >>> element itself, but we put the length first for some of the other
> >>> fields (that appear after these) so there seems to be some malleability.
> >>
> >> That order was also discussed a lot.
> >> https://github.com/tlswg/dtls-conn-id/pull/29
> >> I would prefer, if this is not changed again without strong arguments!
> >
> > Thanks for the pointer!
> > I am not sure that the specific question about injectivity was raised
> > there, though.  (The topic of whether "seq_num" includes epoch was raised
> > but I did not see a clear resolution on my first reading, just
> > https://github.com/tlswg/dtls-conn-id/pull/29#discussion_r246152379)
> >
> > Specifically, the question of "injectivity" is referring to a scenario
> > where I can use different actual values for (cid, cid_length,
> > length_of_DTLSInnerPlaintext, etc.) but have a collision in the constructed
> >
> > cid + cid_length + length_of_DTLSInnerPlaintext + ...
> >
> > (Hmm, we should probably say that length_of_DTLSInnerPlaintext is a 2-byte
> > field...)
> >
> > Attempting to construct a trivial example on the fly, (hex)
> >
> > 01 01 02 02 01 <513 bytes of plaintext content>
> >
> > could be cid_length=1, cid=0x01, length_of_DTLSInnerPlaintext=0x0202,
> > DTLSInnerPlaintext.content = 0x01 <513 bytes>, or it could be
> > cid_length=2, cis=0x0101, length_of_DTLSInnerPlaintext=0x0201,
> > DTLSInnerPlaintext.content = <513 bytes>.  The possibility of such a
> > collision weakens the cryptographic protection and should be avoided.
> >
> 
> If that is going to be changed, the early adopters run into trouble with
> their deployments!

I'm not sure I follow.  Are you saying that if there is a theoretical
problem with the construction it would have been exposed by implementation
testing?

> The cid length is not on the wire, so on the wire is (cid 01 01)
> 
> > 01 01 02 01 <513 bytes of plaintext content>
> 
> Therefore I don't understand, WHO will inject something, which is not on
> the wire. For me that would only be the peer's implementation, which
> extracts it's "own" CID wrong, or a "spoofed CID" (maybe that's the time
> to read my proposal about a CID Authenti

Re: [TLS] HelloRetryRequest question (was Re: TLS 1.3 Problem?)

[Benjamin Kaduk]

On Wed, Sep 30, 2020 at 05:24:21PM -0400, Michael D'Errico wrote:
> I wrote:
> 
> > Also the server can't be actually stateless since
> > it needs to know the HelloRetryRequest message
> > for the transcript hash, right?
> 
> How can you even implement stateless HRR with a
> pseudo-session-ticket in the "cookie"?  The server
> needs to know the full HRR message to calculate the
> transcript hash, but this can't be part of the ticket
> since the ticket is included within the HRR, thus
> changing it

The HRR is presumed to be a deterministic function of the
initial ClientHello, and as I discussed in my earlier message,
the server can reconstruct the initial ClientHello from the
second ClientHello and verify it against the hash in the cookie.

-Ben

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

Re: [TLS] Is stateless HelloRetryRequest worthwhile? (was Re: TLS 1.3 Problem?)

[Benjamin Kaduk]

Hi Mike,

On Wed, Sep 30, 2020 at 01:20:59PM -0400, Michael D'Errico wrote:
> > The costs you describe are trivial.
> 
> The general idea among developers these days that CPU
> cycles are free is a huge problem.
> 
> You didn't answer my biggest question, though, which was
> whether you (or anybody else!) has had success using stateless
> HelloRetryRequest to increase the number of connections a
> datacenter can handle due to the fact that the servers were
> memory-bound.  The amount of memory to hold the first

Could you say a bit more about why you think that demonstration
of production-grade usage in (non-D) TLS is needed in order to justify
this portion of the specification?  Note that you can use HRR
without cookie just fine.

The HelloRetryRequest message has to exist in TLS 1.3 in order
to cope with the case where the client's optimistic key_share
is not acceptable to the server, and another round-trip is
needed in order to get key shares for the proper group.

Give that there will be an HRR message, it seems/seemed quite
prudent to build out all the bits that DTLS would need from a HRR,
since we knew DTLS 1.3 was coming in short order, and we want
DTLS 1.3 to be as small a diff from TLS 1.3 as possible.

While you might in theory want to or be able to use TLS 1.3
HRR+cookie to decrease state keeping at the server, that's not (IMO)
the main reason it exists, and so I don't see a need for anyone
to demonstrate that they have done so in order to justify this
portion of the specification.  The text about allowing stateless offload
being a primary purpose for cookie can be true even though it is not
directly utilized in regular TLS.


With respect to the "hash of the ClientHello" question and how much
state is needed, the idea is that the ways in which the second
ClientHello can differ from the original ClientHello are tightly
constrained, such that the original ClientHello can be reconstructed
by the server given the second ClientHello and an honest client.
If the hash of the reconstructed version does not match the hash
saved in the cookie, you assume that some form of attack is underway
and abort the connection.  You can also do fancier things as has
already been described, but that is part of the origin of the "hash of the
ClientHello" text.  (You do also need the hash value to complete the
transcript, as Watson noted.)

With respect to HRR being a weird instance of ServerHello instead of
a "proper" message in its own right, yes, that is weird.  It was
originally a separate message, and then real-world deployment showed
that there were too many deployed middleboxes that would choke on a
new message type, and we had to come up with a *lot* of awkward
hacks to provide "middlebox compatibility mode" (see section D.4).
It seems simpler to make HRR always be the middlebox-compatible version
rather than have two ways to spell it, so that's why it's the way it is.

-Ben

P.S. If you felt like doing some experiments to see how the
stateless HRR affects the memory/CPU balance, it is implemented
in openssl.

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

Re: [TLS] AD review of draft-ietf-tls-dtls-connection-id-07

[Benjamin Kaduk]

Hi Achim,

On Fri, Sep 04, 2020 at 08:58:51AM +0200, Achim Kraus wrote:
> Hi Ben,
> 
> see my comments inline.
> 
> Generally you may read the closed issues or PRs with the proper keywords
> in https://github.com/tlswg/dtls-conn-id.
> 
> FMPOV most stuff has been discussed over and over. For me, in many cases
> there are not that strong arguments for the choosen option over the
> others. But these discussion have been at that time. For now, I'm not
> sure, if changing details will bring that benefit.
> So, please, only address and change things, which are really important.

Sure.  If there are particular PRs/issues or search queries that are
relevant, that can help me revisit the previous discussions.

> 
> Am 04.09.20 um 01:02 schrieb Benjamin Kaduk:
> > Hi all,
> >
> > Sorry for the slow processing time -- my queue is still longer than I am
> > happy with.
> >
> > There's a few apparent inconsistencies that we'll need to tighten up,
> > but I don't think there's anything particularly problematic.
> > I made a PR for most of the editorial stuff:
> > https://github.com/tlswg/dtls-conn-id/pull/75
> > And having pulled the github repo up, it looks like there's a few open
> > issues and PRs still, there -- what's the status of those?
> >
> 
> #73 FMPOV it's worth to address the issue Thomas found.
> I would prefer a wording, which point to RFC6347, 4.1.2.1 and explain
> not to use the option "If a DTLS implementation chooses to generate an
> alert".

Seems reasonable to me, thanks.

> > I wonder whether, as a rhetorical device, it would be helpful to give
> > the new record payload structure a new name (DTLSCIDCiphertext?) to
> > distinguish it from the RFC 6347 DTLSCiphertext.  Then we could write
> > things like "in order to distinguish between DTLSCiphertext and
> > DTLSCIDCiphertext", "the DTLSCIDCiphertext record format is only used
> > once encryption is enabled", etc.
> >
> > Section 3
> >
> > For sending, if a zero-length CID has been negotiated then the RFC
> > 6347-defined record format and content type MUST be used (see
> > Section 4.1 of [RFC6347]) else the new record layer format with the
> > tls12_cid content type defined in Figure 3 MUST be used.
> >
> > I'm glad that we take a clear stance on what content-type to use for
> > zero-length CIDs, though I forget what the reasoning was to fall this
> > way vs requiring that the tls12_cid ContentType is used whenever CIDs
> > are negotiated.  I see how this approach makes some processing easier
> > (there is always a CID present when the ContentType is used), but it
> > does have the drawback of requiring use of actual CIDs in order to
> > get encrypted content-type.  If you could remind me why this approach
> > was chosen, that will be helpful for subsequent discussions/IESG
> > review/etc.
> 
> There have benn some discussion about that, see
> 
> https://github.com/tlswg/dtls-conn-id/issues/22
> https://github.com/tlswg/dtls-conn-id/issues/28
> 
> So, I'm also glad that in the end of the discussion there was a
> consense. I'm not sure, but I think that comment
> 
> https://github.com/tlswg/dtls-conn-id/issues/28#issuecomment-458032109
> 
> made mainly the decission.

Excellent; thank you for these references.
 
> 
> >
> > For receiving, if the tls12_cid content type is set, then the CID is
> > used to look up the connection and the security association.  If the
> > tls12_cid content type is not set, then the connection and security
> > association is looked up by the 5-tuple and a check MUST be made to
> > determine whether the expected CID value is indeed zero length.  If
> > the check fails, then the datagram MUST be dropped.
> >
> > I guess there's maybe a risk that an attacker sets up a CID-ful
> > connection on a given 5-tuple and then disappears, thereby denying
> > the target of the attack the ability to use a CID-less DTLS association
> > on that 5-tuple.  But it would be hard to swamp all the ports, so it's
> > only likely to be an issue when fixed ports are used on both sides ...
> > which is known to happen sometimes.  Perhaps we should document this in
> > the security considerations.
> >
> 
> I'm not sure, if I understand that well.
> Do you assume, that in a network envirnoment, where the 5-tuple is not
> stable, someone may use a CID and so block the (instable) 5-tuple? Yes,
> but in that network your peer MUST anyway use new handshakes and so the
> CID usage will be overwriten by t

[TLS] AD review of draft-ietf-tls-dtls-connection-id-07

[Benjamin Kaduk]

Hi all,

Sorry for the slow processing time -- my queue is still longer than I am
happy with.

There's a few apparent inconsistencies that we'll need to tighten up,
but I don't think there's anything particularly problematic.
I made a PR for most of the editorial stuff:
https://github.com/tlswg/dtls-conn-id/pull/75
And having pulled the github repo up, it looks like there's a few open
issues and PRs still, there -- what's the status of those?

I wonder whether, as a rhetorical device, it would be helpful to give
the new record payload structure a new name (DTLSCIDCiphertext?) to
distinguish it from the RFC 6347 DTLSCiphertext.  Then we could write
things like "in order to distinguish between DTLSCiphertext and
DTLSCIDCiphertext", "the DTLSCIDCiphertext record format is only used
once encryption is enabled", etc.

Section 3

   For sending, if a zero-length CID has been negotiated then the RFC
   6347-defined record format and content type MUST be used (see
   Section 4.1 of [RFC6347]) else the new record layer format with the
   tls12_cid content type defined in Figure 3 MUST be used.

I'm glad that we take a clear stance on what content-type to use for
zero-length CIDs, though I forget what the reasoning was to fall this
way vs requiring that the tls12_cid ContentType is used whenever CIDs
are negotiated.  I see how this approach makes some processing easier
(there is always a CID present when the ContentType is used), but it
does have the drawback of requiring use of actual CIDs in order to
get encrypted content-type.  If you could remind me why this approach
was chosen, that will be helpful for subsequent discussions/IESG
review/etc.

   For receiving, if the tls12_cid content type is set, then the CID is
   used to look up the connection and the security association.  If the
   tls12_cid content type is not set, then the connection and security
   association is looked up by the 5-tuple and a check MUST be made to
   determine whether the expected CID value is indeed zero length.  If
   the check fails, then the datagram MUST be dropped.

I guess there's maybe a risk that an attacker sets up a CID-ful
connection on a given 5-tuple and then disappears, thereby denying
the target of the attack the ability to use a CID-less DTLS association
on that 5-tuple.  But it would be hard to swamp all the ports, so it's
only likely to be an issue when fixed ports are used on both sides ...
which is known to happen sometimes.  Perhaps we should document this in
the security considerations.

   When receiving a datagram with the tls12_cid content type, the new
   MAC computation defined in Section 5 MUST be used.  When receiving a
   datagram with the RFC 6347-defined record format the MAC calculation
   defined in Section 4.1.2 of [RFC6347] MUST be used.

I guess that "4.1.2" includes "4.1.2.5 New Cipher Suites", so this is
not inadvertently closing off extensibility (not that we expect much in
the way of new 1.2 ciphersuites)...right?

Section 4

   When CIDs are being used, the content to be sent is first wrapped
   along with its content type and optional padding into a
   DTLSInnerPlaintext structure.  This newly introduced structure is

Is it worth mentioning that this is anlogous to the TLS 1.3
TLSInnerPlaintext?  (I do see that we have such a reference a couple
paragraphs later in the context of the record padding functionality.)

   enc_content  The encrypted form of the serialized DTLSInnerPlaintext
  structure.

In Section 5.2 we refer to the DTLSCiphertext.enc_content as
the intermediate encrypted stuff used as input to the MAC for
Encrypt-then-MAC processing, which maps up well to this description, but
is in conflict with DTLSCiphertext being the bits that actually go on
the wire.  So we seem to be internally inconsistent about whether
enc_content includes the EtM MAC.  Most likely it will be easiest to
address this in Section 5.2, though.

Section 5.x

   MAC(MAC_write_key, seq_num +

The TLS 1.2 notation is "seq_num" for the implicit sequence number, but
DTLS 1.2 says that the MAC input is the concatenation of the DTLS epoch
and the DTLS (explicit) sequence number.  I do not see this
concatenation given the name "seq_num" anywhere, so I think we need to
reformulate this expression.

   cid +
   cid_length +

Does this construction preserve injectivity?  It seems easier to reason
about when the length of an element is always before or always after the
element itself, but we put the length first for some of the other
fields (that appear after these) so there seems to be some malleability.

Section 6

   -  There is a strategy for ensuring that the new peer address is able
  to receive and process DTLS records.  No such test is defined in
  this specification.
   [...]
   Application protocols that implement protection against these attacks
   depend on being aware of changes in peer addresses so that they can
   engage the necessary mechanisms.  When delivered such an even

Re: [TLS] AD review of draft-ietf-tls-oldversions-deprecate-06

[Benjamin Kaduk]

Hi Kathleen,

Also inline.

On Wed, Aug 12, 2020 at 04:29:56PM -0400, Kathleen Moriarty wrote:
> Hi Ben,
> 
> Thanks for your review.  Some initial responses are inline.
> 
> On Sun, Jul 26, 2020 at 5:22 PM Benjamin Kaduk  wrote:
> 
> > Thanks for putting together the -06 based on my preliminary comments, and
> > my apologies for taking so long to get back to it.  It turns out that going
> > through the 80-odd documents we update takes a while!
> >
> >
> > I have a bunch of suggestions that are basically editorial, that I'll
> > make a pull request for (along with suggested changes for several of the
> > following comments).  It's up at:
> > https://github.com/tlswg/oldversions-deprecate/pull/3
> 
> 
> Thanks for that!
> 
> >
> >
> > We mention in the Abstract (but not Introduction!) that this document
> > moves 2246 and 4346 (but not 6347!) to the historic state.
> > Unfortunately, this is slightly problematic from a process perspective,
> > since the current way to make things Historic
> > (
> > https://www.ietf.org/about/groups/iesg/statements/designating-rfcs-historic-2014-07-20
> > )
> > requires a separate "status change document" that gets its own IETF LC,
> > to effectuate the status change.  Most references to the status change
> > document can be replaced by this RFC after it's published, but formally
> > the move to historic is *not* done by this document.  I've pulled into
> > my pull request the language used in RFC 8429 to describe moves to
> > Historic; please make sure to reproduce that language in the
> > Introduction as well as the Abstract.
> >
> 
> Do you need us to submit a draft to request that status change?

No -- it's done purely in the datatracker without an I-D, so I will plan to
do that.  (Unfortunately, it has to be one status-change document per
status-change, so it'll be a lot of clicking for me, but that's life.)

> >
> > I found three documents (3656, 4540, 7562) in the list of update targets
> > that are on the ISE (not IETF) stream.  I had talked to Adrian during my
> > preliminary review, and in principle it is permissible to make those
> > updates as part of this document, but we will need specific ISE approval
> > to do so.  I am supposed to sync up with him during IETF LC, but the
> > document needs to be updated to clarify that the updates of ISE
> > documents are/will be done with permission of the ISE.  (Please also try
> > to double-check that the list is complete; I didn't find an
> > authoritative list of "all documents on the ISE stream" to grep against,
> > and I didn't try to have something parse rfc-index.xml to output such a
> > list.
> >
> 
> OK, so you'd like a list added and that's not in your pull request, is that
> right?  We'll figure it out. Thanks in advance with the coordination with
> Adrian.

That's correct, this is not in my pull request (not least because that list
of three documents is incomplete -- I sent a more-likely-complete list of 6
documents in an off-list follow-up.
https://www.rfc-editor.org/search/rfc_search_detail.php?stream_name=Independent&page=All
will get a (presumably authoritative) list of ISE-stream documents, FWIW.

> 
> >
> > I note that in addition to our BCP 195 update (called out in Section 6),
> > we also update 3552, which is BCP 72.  This update is quite incidental
> > (compared to our BCP 195 update), so it seems clear that having this
> > document be part of BCP 195 is correct.
> >
> 
> Are you asking here to include an update to RFC3552?   Thanks.

No change needed here, I think -- just noting that we already list RFC 3552
as being updated, but that we don't need to be part of BCP 72, since the
update in question is largely incidental.

> >
> > Section 1.1
> >
> > I went through all 83 of the references in the big list, that are
> > supposed to be ones that "normatively reference TLS 1.0/1.1 or DTLS 1.0,
> > as well as the shorter list of already-obsoleted documents.
> >
> > I won't bore you with my full notes, but there are some particular
> > things that stood out from the review:
> >
> > - We have a separate list of updates for documents that are already
> >   obsolete (but don't say much about why we're going go the extra
> >   bother).  However, three of the documents in our main list of updates
> >   (4743, 4744, and 6460) are already Historic, and presumably should be
> >   treated more like the already-obsolete ones.
> >
> 
> Obsolete does not mean the same thing as depreca

Re: [TLS] Draft minutes for TLS at IETF 108

[Benjamin Kaduk]

On Wed, Aug 05, 2020 at 10:30:39AM +, tom petch wrote:
> From: TLS  on behalf of Christopher Wood 
> 
> Sent: 04 August 2020 19:16
> 
> The official minutes are now up:
> 
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_minutes-2D108-2Dtls_&d=DwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=bJwecPEDnXCm7Huw2ovjHwHyzCjhyu2kGMG-qijduH0&s=ksaUzUpfyd4LFplcfnjfXdGBN-jTrMiqS2Z1vk_Iftw&e=
>  
> 
> 
> What is Benjamin talking about at the end?
> 
> It looks as if you are proposing action on all or some RFC that have TLS 1.0 
> or 1.1 as MTI, related to oldversions-deprecate but that is a guess from 
> reading between the lines and that topic is a live one for me so I would 
> appreciate clarity.

oldversions-deprecate is already taking action on all RFCs that have TLS 1.0 or
1.1 as MTI (there are some 80-odd documents in the Updates: header).  The
particular itesm I was mentioning in the meeting relate to various subsets of
those documents that may need some additional handling on top of the basic
"don't use TLS 1.0/1.1; use 1.2 and 1.3 instead" that is currently the content
of the updates.  Details are at 
https://mailarchive.ietf.org/arch/msg/tls/K9_uA6m0dD_oQCw-5kAbha-Kq5M/
So:

- RFC 5469 defines DES and IDEA ciphers that are not in TLS 1.2; the
  document as a whole should be historic

- The downgrade-detection SCSV of RFC 7507 is probably in a similar boat

- We should be more clear about "if the document being updated says you
  MUST use TLS 1.0/1.1, that part is removed"

- No change proposed w.r.t. MTI ciphers (even though the old MTI ciphers
  are no longer considered very good)

Were there additional specific items you were unsure about?

-Ben

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

Re: [TLS] draft-ietf-tls-dtls-connection-id-07 / IANA connection_id

[Benjamin Kaduk]

Hi Achim,

My apologies for the URL mangling by my corporate spam filter.

On Wed, Jul 22, 2020 at 08:53:21AM +0200, Achim Kraus wrote:
> Dear list,
> 
> are there any news about the draft-ietf-tls-dtls-connection-id and the
> IANA registration of the connection_id?
> 
> According
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dtls-2Ddtls-2Dconnection-2Did&d=DwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=HetqGKNPLld3ESyjZr6lPT8gnkN8LiIxcivjicGpyeg&s=kAlzAEjg0E4P_Cw7G3afL6NHvcFJpJLl72gJVzBvrJ8&e=
>   the
> draft expired on April 23, 2020 and according
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iana.org_assignments_tls-2Dextensiontype-2Dvalues_tls-2Dextensiontype-2Dvalues.xhtml&d=DwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=HetqGKNPLld3ESyjZr6lPT8gnkN8LiIxcivjicGpyeg&s=poEk1-YL4mzxACY3b-Ldn9NtcPOSd-ZvDKXJcbQ3Ep0&e=
> the assigned value expired on 2020-07-02.

There seems to have been some oversight, as this assignment was not included
in a report of "early allocations assigning in the next 60 days" that was 
produced
on 2020-06-15.  I have asked IANA to investigate (and indicated that this
extension's allocation should be renewed).

The draft itself is essentially done from the WG's point of view, with just
the two PRs you note left to merge.  It has been waiting for quite some time for
me to perform an AD evaluation and start an IETF Last Call on it; I expect to do
so in the next couple weeks.

Thanks,

Ben

> I still very interested in this extension, it makes coap over dtls 1.2 a
> very powerful technology for the cloud and NB IoT.
> 
> Currently two pending threats are discussed, see the PRs in
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_dtls-2Dconn-2Did&d=DwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=HetqGKNPLld3ESyjZr6lPT8gnkN8LiIxcivjicGpyeg&s=6LWHz8pLHziy_jeL2sXwJnw4Y7gz84VzFUe0ur4RsDg&e=
>   .
> 
> One of both is in my opinion a general one using UDP, several
> countermeasures are discussed, including RRC. Let me add, that in my
> opinion, it's also about to chose cid for the right use-case, and not
> generally. That would mostly eliminated the DDoS threat, if the use-case
> doesn't offer an amplification.
> The other one requires in my opinion a remark about not using the option
> of RFC 6347 to generate an alert on invalid MACs, if the cid is used.
> Potentially, if of any interest at all, an additional remark about
> AES-CBC, the CID length and "lucky 13" maybe added, though the cid
> changes the 13.
> 
> For me this looks much more, that the authors are too busy with other
> work and not that this draft doesn't make sense anymore. Therefore I
> would appreciate, if the temporary IANA registration for the
> connection_id could be extended by an additional year.
> 
> Best regards
> Achim Kraus
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=HetqGKNPLld3ESyjZr6lPT8gnkN8LiIxcivjicGpyeg&s=FbOzAxOPoG1SVAsJCPteFfbyv3RYaOwBj5OuZTxcerk&e=

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