From nobody Tue Oct 2 02:23:20 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47799130DF9 for ; Tue, 2 Oct 2018 02:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhX4wRZCPuYb for ; Tue, 2 Oct 2018 02:23:11 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90F2E12F18C for ; Tue, 2 Oct 2018 02:23:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2F1C3300AA9 for ; Tue, 2 Oct 2018 05:23:09 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id JxA2wJCLM1We for ; Tue, 2 Oct 2018 05:23:08 -0400 (EDT) Received: from 183-0-10-193.dhcp.sunet.se (unknown [193.10.0.183]) by mail.smeinc.net (Postfix) with ESMTPSA id F1DAA300A0A; Tue, 2 Oct 2018 05:23:07 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Russ Housley In-Reply-To: <20180926192916.GA31766@LK-Perkele-VII> Date: Tue, 2 Oct 2018 05:23:07 -0400 Cc: IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: References: <1231917830.3727154.1535119783361.JavaMail.zimbra@enst.fr> <20180827163405.GA19628@LK-Perkele-VII> <235113009.594519.1535390674699.JavaMail.zimbra@enst.fr> <6170599.o3dyPvx8Gh@pintsize.usersys.redhat.com> <1379020500.16565707.1537977448089.JavaMail.zimbra@enst.fr> <20180926192916.GA31766@LK-Perkele-VII> To: Mounira Msahli X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 09:23:16 -0000 The document says: /* Managed by IANA */ enum { X509(0), RawPublicKey(2), 1609Dot2(?), /* Number 3 will be requested for 1609.2 */ (255) 103097(?), /* Number 4 will be requested for 103097 */ (255) } CertificateType; Two things... 1) The "(255)" should only appear at the end. The one in the middle = should go away. 2) Don't the requested additions need to begin with letters? IEEE1609Dot2(?), /* Number 3 will be requested for IEEE 1609.2 = */ ETSI103097(?), /* Number 4 will be requested for ETSI TS 103 097 = */ Russ= From nobody Tue Oct 2 07:08:46 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A288130E9B for ; Tue, 2 Oct 2018 07:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=onboardsecurity-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHrGerxkogI2 for ; Tue, 2 Oct 2018 07:08:39 -0700 (PDT) Received: from mail-pl1-x643.google.com (mail-pl1-x643.google.com [IPv6:2607:f8b0:4864:20::643]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8E2A130E9D for ; Tue, 2 Oct 2018 07:08:38 -0700 (PDT) Received: by mail-pl1-x643.google.com with SMTP id p5-v6so1636595plk.3 for ; Tue, 02 Oct 2018 07:08:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onboardsecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dvfra+igSzSuvrm6V06PRqF/WftPoFimXSrNOIQ/mMI=; b=h/OFXJ5Zh7ll9zHKXus6cspEVc/1QkqJrGcPfTm+/qQZZbiSwbxURK/5atMMXWiuY+ Oi3XM0G8jDJG0J8f/rfaPiGgCkwHQmWjbmqzL3WRdVJkvcAUzXiXCwuqfIEboO5elxcL MX+ZDDD4cdnK+XoZp3DEQgg45w1ut1N2IvlFV76hR9gRhzln6mCYPXLwEmLdxwQASF24 Sviy3IkeB1e/ZnClzJa50leuqGIxyph7ypaegrDrWB4c774L6LMtgwCdVQ1XOen7YZYg Tmc2SmjFqpgu6bz5+r4zvnBqE1G6xS24HAUzxEhd08Jvnc9X4VjiiQxFdbZ1mqr3dkiZ 0kSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dvfra+igSzSuvrm6V06PRqF/WftPoFimXSrNOIQ/mMI=; b=HdVzAj6i/y59rhbT9SE1PCPKHhgHOMEPtzl/B0liuzudvMeRGWCIrTLbplKa6DWvSK S4AFuxgSxQu7qfVuWuAO+IrLrZWACj6f2sS9tumEw5Bk4JGneY/gUkcxuB7WvAJ0O3Jv G8DVmFxnMklAd8EwXdCiDbN8AC6GsEyWFTlk/Q6c2s8J/EvA+PXXkXfxjGhoaEWnWFy5 BRX+/5CXnzR6Xyl+7Ysl4VE9T/TA1ANO+dOentQ81LYadvum3T5MOLLWS/nVKjWv4WOz eppzjYE630NTfmSlNQlkqQBAC74x2Lz7rByEn+a1ffjdk9PF9/QvSNJvMJMWRby1Q4pw 2VyQ== X-Gm-Message-State: ABuFfohPvm95PYiGewM0vFwCKOh9HVkroyP7ph4h7POvjjdHwcBDK+RC wDW1lnH2FDRkBDtfdUdKURxZXT24u4LCeihGr0/cPQ== X-Google-Smtp-Source: ACcGV62GHxQKML0JmQeqhmASSrq5ddTeWkpJxhxvFHYsQfdV5Dgg/ai+sdrxbE0D1wp7hOjLFfAQiFbs3YYd/eju3pU= X-Received: by 2002:a63:f409:: with SMTP id g9-v6mr11390277pgi.369.1538489318070; Tue, 02 Oct 2018 07:08:38 -0700 (PDT) MIME-Version: 1.0 References: <1231917830.3727154.1535119783361.JavaMail.zimbra@enst.fr> <20180827163405.GA19628@LK-Perkele-VII> <235113009.594519.1535390674699.JavaMail.zimbra@enst.fr> <6170599.o3dyPvx8Gh@pintsize.usersys.redhat.com> <1379020500.16565707.1537977448089.JavaMail.zimbra@enst.fr> <20180926192916.GA31766@LK-Perkele-VII> In-Reply-To: <20180926192916.GA31766@LK-Perkele-VII> From: William Whyte Date: Tue, 2 Oct 2018 10:08:26 -0400 Message-ID: To: Ilari Liusvaara Cc: Mounira Msahli , "" Content-Type: multipart/alternative; boundary="0000000000004b74e905773f75b6" Archived-At: Subject: Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 14:08:45 -0000 --0000000000004b74e905773f75b6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ilari, >> - The construction looks like it mixes different kinds of structures: 1609.2 Data of type signed versus TLS 1.3 signature. I do not think this is cryptographically kosher. In fact, I think the call for "extreme care" for certain kinds of modifications from TLS 1.3 specification appiles here. >> That is, with 1609.2 what is passed to actual raw signature is not TLS 1.3 signature structure, nor something compatible with it (the invariant part with dedicated context is only up to and including the zero separator). However, I do not think that changing the context and then hacking what comes afterwards (altough it seems cryptographically kosher) is a good idea for implemntation reasons. You're right, it uses the 1609.2 data structure. The rationale is as follows: Software: Most 1609.2 libraries offer only a high-level API for signing and verification, where: On signing: the input is the data, a handle for the key, and a set of options, and the output is a 1609.2 signed data. On verification: the input is the Ieee1609Dot2Data output by signing, the certificate, and some options, and the output is either =E2=80=9Cvalid=E2= =80=9D or an error code. As such, using a 1609Dot2Data in the Signature field doesn=E2=80=99t requir= e any software changes to 1609.2 libraries. It does require an additional change to the TLS library, which is to check if a 1609.2 certificate is being used and if so to send the Signature field to a 1609.2 verification engine rather than a =E2=80=9Craw=E2=80=9D ECDSA verification engine, but the TLS = library is being changed anyway and this approach allows the changes to be confined to a single codebase. Philosophy: 1609.2 certificates are by intent more tightly coupled to the signing mechanism than X.509 certificates. 1609.2 specifies consistency between a certificate and the PDU that it signs in terms of validity period, (optionally) geographic location, and application permissions (PSID and SSP), and it would be unfortunate to create a setting in which they can be less tightly coupled. In particular, since a certificate can contain more than one PSID, it=E2=80=99s useful to state the PSID which the certificate = holder is intending to assert in a given context. The most natural way to do this is to use an IEEE1609Dot2Data. A rationale for continuing to use the raw signature field would be to make the change to TLS as minimal as possible. This is a reasonable rationale, but we would argue that allowing the signature format to depend on the certificate type does not break the TLS model as much as allowing a different entry point to 1609.2 cryptographic processing breaks the 1609.2 model. Since one or the other has to be changed, and since the TLS implementation is being changed already, we prefer to keep the changes to the TLS. If it would help, we could add this rationale to the Security Considerations section. >> - Bleh: Hardcoding SHA-256 in place that requires a strong hash. One more place to mind if SHA-256 someday breaks. The hash looks extraneous too, as what needs to be signed is not long. 1609.2 currently only supports SHA-256 for message hashing -- it's extensible, in that it has a hash algorithm identifier that can in principle be extended with additional identifier values, but currently only SHA-256 is defined for message hashing. The hardcoding of SHA-256 in this draft should be read as informative text about a constraint that exists anyway in 1609.2. If 1609.2 is extended to support additional hash algorithms we'll circle back and change this part of this draft. >> - Changing CV format with certificate format could create problems with existing TLS implmentations, as there is no precendent for such change. In fact, there even isn't an extension that changes that (and such extension would require very careful analysis). I accept that this is a valid concern in general and complicates the TLS signing/verification logic. As described above, we reluctantly decided that this was a preferable approach to using raw signatures with 1609.2 certificates, because when you're using 1609.2 certificates it's because you want the tighter binding to owner permissions that you get from 1609.2 and as such it's important to use 1609.2 certificates accompanied by the 1609.2 signed data structure. I don't think this is a direct security concern, but I acknowledge that the additional complexity in TLS implementations is regrettable. >> And what about TLS 1.2, which does not use CV for server side, and has different format CV for client side? I'll be honest, when I drafted this part of the document I was thinking only about TLS 1.3. I don't have a strong feeling that 1609.2 certificates should be usable in TLS 1.2. We'd be happy to take guidance about how this could be integrated into TLS 1.2. Note re the comment about existing implementations above that if you're focusing on TLS 1.3, then there are fewer and less well-established existing implementations than there are with TLS 1.2, so I think the existing implementations concern is also diminished. >> - Nasty hack for psid that would not be crypographically questionable would be to throw it inside first certificate entry (just leave the overall entry length as 3 bytes to avoid trouble with certificate message parsing). Agreed, but also agreed that it's a hack :-) >> - The timestamp looks very questionable. What is it for? What if the generating clock is wrong (clocks are wrong depressingly often)? It seems that TLS exchanges are occuring "now" from viewpoint of the endpoints. Again, this is a constraint of using the full 1609.2 processing: the 1609.2 verification process requires that a generation time is available so that the verifier can check that the generation happened during the validity period of the certificate. Historically, this requirement came in because 1609.2 is in general used to authenticate broadcast messages, and so the generation time is the only way to guarantee freshness. In the TLS setting, freshness is guaranteed by the live protocol, so this doesn't add value, but 1609.2 libraries aren't configurable to turn this check off and including the generation time isn't a lot of overhead. The draft doesn't propose that the TLS handshake process makes any use of the generation time other than the use (which isn't explicitly stated but is implicit in the use of 1609.2 verification) to ensure the handshake was valid when generated; in other words, there's no stated requirement for consistency between the client and server clocks, the requirement is for consistency between the signer's clock and its use of its own certificate. Does this make the proposal seem more palatable? Cheers, William On Wed, Sep 26, 2018 at 3:29 PM Ilari Liusvaara wrote: > On Wed, Sep 26, 2018 at 05:57:28PM +0200, Mounira Msahli wrote: > > Hi all, > > > > Please find attached a new version of the draft. We took account of > > pevious TLS group comments. William, editor of 1609.2, proposes to > > add the section certificate verify (section 4.3 in the draft). > > It concerns the addition of IEEE 1609.2 signature for the the > > ertificate verify. > > I took a brief look. The CertificateVerify changes look suspect: > > - The construction looks like it mixes different kinds of structures: > 1609.2 Data of type signed versus TLS 1.3 signature. I do not think > this is cryptographically kosher. In fact, I think the call for > "extreme care" for certain kinds of modifications from TLS 1.3 > specification appiles here. > > That is, with 1609.2 what is passed to actual raw signature is not > TLS 1.3 signature structure, nor something compatible with it > (the invariant part with dedicated context is only up to and > including the zero separator). However, I do not think that > changing the context and then hacking what comes afterwards > (altough it seems cryptographically kosher) is a good idea for > implemntation reasons. > > - Bleh: Hardcoding SHA-256 in place that requires a strong hash. One > more place to mind if SHA-256 someday breaks. The hash looks > extraneous too, as what needs to be signed is not long. > > - Changing CV format with certificate format could create problems with > existing TLS implmentations, as there is no precendent for such > change. In fact, there even isn't an extension that changes that > (and such extension would require very careful analysis). And > what about TLS 1.2, which does not use CV for server side, and has > different format CV for client side? > > - Nasty hack for psid that would not be crypographically questionable > would be to throw it inside first certificate entry (just leave > the overall entry length as 3 bytes to avoid trouble with certificate > message parsing). > > - The timestamp looks very questionable. What is it for? What if the > generating clock is wrong (clocks are wrong depressingly often)? It > seems that TLS exchanges are occuring "now" from viewpoint of the > endpoints. > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --=20 PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS: wwhyte@onboardsecurity.com --0000000000004b74e905773f75b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ilari,

>> - The construction looks like it mixes different kinds = of structures:
=C2=A0 1609.2 Data of type signed versus TLS 1.3 s= ignature. I do not think
=C2=A0 this is cryptographically kosher.= In fact, I think the call for
=C2=A0 "extreme care" fo= r certain kinds of modifications from TLS 1.3
=C2=A0 specificatio= n appiles here.

>&= gt;=C2=A0 That is, with 1609.2 what is passed to actual raw signature is no= t=C2=A0
=C2=A0 TLS 1.3 signature structure, nor something compati= ble with it
=C2=A0 (the invariant part with dedicated context is = only up to and
=C2=A0 including the zero separator). However, I d= o not think that
=C2=A0 changing the context and then hacking wha= t comes afterwards
=C2=A0 (altough it seems cryptographically kos= her) is a good idea for
=C2=A0 implemntation reasons.
=

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

Software:=C2=A0

Most 1609.2 libraries o= ffer only a high-level API for signing and verification, where:
<= br>
On signing: the input is the data, a handle for the key, and = a set of options, and the output is a 1609.2 signed data.

On verification: the input is the Ieee1609Dot2Data output by signin= g, the certificate, and some options, and the output is either =E2=80=9Cval= id=E2=80=9D or an error code.

As such, using a 160= 9Dot2Data in the Signature field doesn=E2=80=99t require any software chang= es to 1609.2 libraries. It does require an additional change to the TLS lib= rary, which is to check if a 1609.2 certificate is being used and if so to = send the Signature field to a 1609.2 verification engine rather than a =E2= =80=9Craw=E2=80=9D ECDSA verification engine, but the TLS library is being = changed anyway and this approach allows the changes to be confined to a sin= gle codebase.

Philosophy:=C2=A0

1609.2 certificates are by intent more tightly coupled to the signin= g mechanism than X.509 certificates. 1609.2 specifies consistency between a= certificate and the PDU that it signs in terms of validity period, (option= ally) geographic location, and application permissions (PSID and SSP), and = it would be unfortunate to create a setting in which they can be less tight= ly coupled. In particular, since a certificate can contain more than one PS= ID, it=E2=80=99s useful to state the PSID which the certificate holder is i= ntending to assert in a given context. The most natural way to do this is t= o use an IEEE1609Dot2Data.

A rationale for continu= ing to use the raw signature field would be to make the change to TLS as mi= nimal as possible. This is a reasonable rationale, but we would argue that = allowing the signature format to depend on the certificate type does not br= eak the TLS model as much as allowing a different entry point to 1609.2 cry= ptographic processing breaks the 1609.2 model. Since one or the other has t= o be changed, and since the TLS implementation is being changed already, we= prefer to keep the changes to the TLS.

If i= t would help, we could add this rationale to the Security Considerations se= ction.

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

1609.= 2 currently only supports SHA-256 for message hashing -- it's extensibl= e, in that it has a hash algorithm identifier that can in principle be exte= nded with additional identifier values, but currently only SHA-256 is defin= ed for message hashing. The hardcoding of SHA-256 in this draft should be r= ead as informative text about a constraint that exists anyway in 1609.2. If= 1609.2 is extended to support additional hash algorithms we'll circle = back and change this part of this draft.

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

I accept that this is a valid = concern in general and complicates the TLS signing/verification logic. As d= escribed above, we reluctantly decided that this was a preferable approach = to using raw signatures with 1609.2 certificates, because when you're u= sing 1609.2 certificates it's because you want the tighter binding to o= wner permissions that you get from 1609.2 and as such it's important to= use 1609.2 certificates accompanied by the 1609.2 signed data structure. I= don't think this is a direct security concern, but I acknowledge that = the additional complexity in TLS implementations is regrettable.
=
>> And
=C2=A0 what about TLS 1.2, which does= not use CV for server side, and has
=C2=A0 different format CV f= or client side?

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

Note re the comment about existing = implementations above that if you're focusing on TLS 1.3, then there ar= e fewer and less well-established existing implementations than there are w= ith TLS 1.2, so I think the existing implementations concern is also dimini= shed.

>> - Nasty hack for psid that would no= t be crypographically questionable
=C2=A0 would be to throw it in= side first certificate entry (just leave
=C2=A0 the overall entry= length as 3 bytes to avoid trouble with certificate
=C2=A0 messa= ge parsing).=C2=A0

Agreed, but also agreed that it= 's a hack :-)

>> - The timestamp looks v= ery questionable. What is it for? What if the
=C2=A0 generating c= lock is wrong (clocks are wrong depressingly often)? It
=C2=A0 se= ems that TLS exchanges are occuring "now" from viewpoint of the
=C2=A0 endpoints.

Again, this is a = constraint of using the full 1609.2 processing: the 1609.2 verification pro= cess requires that a generation time is available so that the verifier can = check that the generation happened during the validity period of the certif= icate. Historically, this requirement came in because 1609.2 is in general = used to authenticate broadcast messages, and so the generation time is the = only way to guarantee freshness. In the TLS setting, freshness is guarantee= d by the live protocol, so this doesn't add value, but 1609.2 libraries= aren't configurable to turn this check off and including the generatio= n time isn't a lot of overhead.

The draft does= n't propose that the TLS handshake process makes any use of the generat= ion time other than the use (which isn't explicitly stated but is impli= cit in the use of 1609.2 verification) to ensure the handshake was valid wh= en generated; in other words, there's no stated requirement for consist= ency between the client and server clocks, the requirement is for consisten= cy between the signer's clock and its use of its own certificate.
=

Does this make the proposal seem more palatable?
<= div>
Cheers,

William

<= /div>





=
On Wed, Sep 26, 2018 at 3:29 PM= Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
On Wed, Sep 26, 2018 at 05:57:28PM +0200, = Mounira Msahli wrote:
> Hi all,
>
> Please find attached a new version of the draft. We took account of > pevious TLS group comments.=C2=A0 William, editor of 1609.2, proposes = to
> add the section certificate verify (section 4.3 in the draft).
> It concerns the addition of IEEE 1609.2 signature for the the
> ertificate verify.

I took a brief look. The CertificateVerify changes look suspect:

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

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

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

- Changing CV format with certificate format could create problems with
=C2=A0 existing TLS implmentations, as there is no precendent for such
=C2=A0 change. In fact, there even isn't an extension that changes that=
=C2=A0 (and such extension would require very careful analysis). And
=C2=A0 what about TLS 1.2, which does not use CV for server side, and has =C2=A0 different format CV for client side?

- Nasty hack for psid that would not be crypographically questionable
=C2=A0 would be to throw it inside first certificate entry (just leave
=C2=A0 the overall entry length as 3 bytes to avoid trouble with certificat= e
=C2=A0 message parsing).

- The timestamp looks very questionable. What is it for? What if the
=C2=A0 generating clock is wrong (clocks are wrong depressingly often)? It<= br> =C2=A0 seems that TLS exchanges are occuring "now" from viewpoint= of the
=C2=A0 endpoints.


-Ilari

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


--


PLEASE UPDATE YOUR ADDRESS = BOOKS WITH MY NEW ADDRESS: wwhyte@onboardsecurity.com
--0000000000004b74e905773f75b6-- From nobody Tue Oct 2 23:17:20 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61EF81311EA for ; Tue, 2 Oct 2018 23:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ry_HJfcTCL60 for ; Tue, 2 Oct 2018 23:17:15 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09853131090 for ; Tue, 2 Oct 2018 23:17:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1538547435; x=1570083435; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Gwrsf1isVLJ6f2OB6ojOVnZinIGY4H4v8CLlCU7UTTM=; b=R9Q33MY5TzBqWpQ1G788GiizocpB6zFlAqwdY2zxLI1dEhqPWdiYTABD MBUUpNHaIIrfMh0cr6eA9HtwOL0zWeKrcpQUXc2nh/Gn91mxJVETOfM07 G7fPFYwMV443w5EovKBBbZn5kQ2A8v6cWEw3cwJFe4XINsrBWotmhbQtU fj3eAhxlCgvQQywb3YQrBlhK8Zln5DcnZ0D89gqgCdMju+zd4nXNX5YLr 6Dc+nX/kFm3nZuoEk+g4iAlIwRLNaJpeVMKP1UxFQaok1va6ctLlaWxVh EN98i5O3TxnvoNsaETyJy84Nlc3zT0t3DEheLyKxZAMW30Cn9Fb+Z6oa2 w==; X-IronPort-AV: E=Sophos;i="5.54,334,1534766400"; d="scan'208";a="33380072" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.2 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-a.UoA.auckland.ac.nz) ([10.6.2.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 03 Oct 2018 19:17:10 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-a.UoA.auckland.ac.nz (10.6.2.2) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 3 Oct 2018 19:17:09 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Wed, 3 Oct 2018 19:17:09 +1300 From: Peter Gutmann To: Benjamin Kaduk CC: "" Thread-Topic: [TLS] Request to register value in TLS extension registry Thread-Index: AQHUOHgQgYCzmvnTw0+jhiJlS3ncUqUBiyFo//85voCACqR6AIAB5qLV Date: Wed, 3 Oct 2018 06:17:09 +0000 Message-ID: <1538547426940.37433@cs.auckland.ac.nz> References: <1534764197914.55986@cs.auckland.ac.nz> <1537900287727.4977@cs.auckland.ac.nz> <20180925184219.GD19845@akamai.com>,<20181002141336.GN19845@akamai.com> In-Reply-To: <20181002141336.GN19845@akamai.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Request to register value in TLS extension registry X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 06:17:18 -0000 [CC'd back to the TLS list because this affects other TLS work as well]=0A= =0A= Benjamin Kaduk writes:=0A= =0A= >Having looked a bit harder, it seems that perhaps I need to point out that= ,=0A= >if you want IANA to allocate a value, you need to *ask IANA for it*. The= =0A= >tls-reg-review@ietf.org list is not a supported IANA entrypoint;=0A= =0A= That's not what the RFC appears to say:=0A= =0A= Specification Required [RFC8126] registry requests are registered=0A= after a three-week review period on the =0A= mailing list, on the advice of one or more designated experts.=0A= =0A= [...]=0A= =0A= Registration requests sent to the mailing list for review SHOULD use=0A= an appropriate subject (e.g., "Request to register value in TLS bar=0A= registry").=0A= =0A= This is exactly what I did, I sent a registration request to the list for= =0A= review.=0A= =0A= Within the review period, the designated experts will either approve=0A= or deny the registration request, communicating this decision to the=0A= review list and IANA.=0A= =0A= This never happened.=0A= =0A= Did anyone actually test RFC 8447 before it was published? You send a requ= est=0A= to a mailing list that doesn't seem to work, to be reviewed by a secret pan= el=0A= (well, we know that Rich Salz is one member :-), with no public discussion = or=0A= list archives you can examine to see what happened, and in my case no respo= nse=0A= to the registration request submitted as per the RFC.=0A= =0A= Peter.=0A= From nobody Wed Oct 3 05:29:40 2018 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 725F713126D; Wed, 3 Oct 2018 05:29:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.85.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <153856977342.9010.10521757586695280@ietfa.amsl.com> Date: Wed, 03 Oct 2018 05:29:33 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-certificate-compression-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 12:29:34 -0000 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 Certificate Compression Authors : Alessandro Ghedini Victor Vasiliev Filename : draft-ietf-tls-certificate-compression-04.txt Pages : 7 Date : 2018-10-03 Abstract: In TLS handshakes, certificate chains often take up the majority of the bytes transmitted. This document describes how certificate chains can be compressed to reduce the amount of data transmitted and avoid some round trips. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-certificate-compression-04 https://datatracker.ietf.org/doc/html/draft-ietf-tls-certificate-compression-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-certificate-compression-04 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/ From nobody Wed Oct 3 05:36:52 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF4013126D for ; Wed, 3 Oct 2018 05:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ghedini.me Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ah5QQQbcsB93 for ; Wed, 3 Oct 2018 05:36:48 -0700 (PDT) Received: from blastoise.ghedini.me (blastoise.ghedini.me [45.32.158.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DECC130FBD for ; Wed, 3 Oct 2018 05:36:48 -0700 (PDT) Received: from localhost (unknown [IPv6:2a06:98c0:1000:8200:551b:fecd:b73f:7cd4]) by blastoise.ghedini.me (Postfix) with ESMTPSA id 8CF22DF263 for ; Wed, 3 Oct 2018 12:36:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ghedini.me; s=mail; t=1538570206; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=eh3Rr8RgYvlQlJAHtgAShF+Mj/iMNDLTz/9sIhPNQHM=; b=acaTH94Pz9OoQOAeGfU+C0hKPPLplF7CgyuOA0SLJTA+DFlMRsIcR7KUpoKkWh5UR5fiqT kYQom2g7X4a42XEuMg5Kl4GXj+G6teyME1YUxOYZCk+3uPtZPNBewE5Ag1VEperhievNb/ EwU6W4CFuXEmHzfUajx+6lXZnePGpBg= Date: Wed, 3 Oct 2018 13:36:43 +0100 From: Alessandro Ghedini To: tls@ietf.org Message-ID: <20181003123643.GA5454@mandy.flat11.house> References: <153856977342.9010.10521757586695280@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <153856977342.9010.10521757586695280@ietfa.amsl.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 12:36:51 -0000 On Wed, Oct 03, 2018 at 05:29:33AM -0700, internet-drafts@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 Certificate Compression > Authors : Alessandro Ghedini > Victor Vasiliev > Filename : draft-ietf-tls-certificate-compression-04.txt > Pages : 7 > Date : 2018-10-03 > > Abstract: > In TLS handshakes, certificate chains often take up the majority of > the bytes transmitted. > > This document describes how certificate chains can be compressed to > reduce the amount of data transmitted and avoid some round trips. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-certificate-compression-04 > https://datatracker.ietf.org/doc/html/draft-ietf-tls-certificate-compression-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-certificate-compression-04 This is just a tiny update with a few small fixes and the addition of the early code points assigned by IANA. In other news, Chrome landed support for certificate compression in canary back in July, and Cloudflare deployed support on its edge servers a few weeks ago. The data we've seen on the Cloudflare side looks quite promising so far, although I haven't had the time to do a full analysis yet. We are seeing reductions in certificates sizes between 1.5-2 KB for both ECDSA and RSA (meaning a full QUIC packet if not more), with average compressed size hovering around 2.1-2.4 KB for ECDSA and 2.5-3.5 KB for RSA. The only remaining open issue is the potential attack illustrated by Subodh a few months ago https://www.ietf.org/mail-archive/web/tls/current/msg25851.html >From the reaction on that mailing list discussion, and from talking to people at the last IETF, it seems to me that the attack doesn't appear to worry people much and that there isn't much interest in fixing it. Though I thought I'd mention it again to see if people have anything to add to it, and see if we can agree on whether we should do anything about it. Other than that it looks like the draft is in a pretty good shape at this point, so it'd be nice to have some additional review, and then see if it can proceed to the next step (which I think would be WGLC). Cheers From nobody Wed Oct 3 07:04:23 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6317C13129A for ; Wed, 3 Oct 2018 07:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFFMqaW3NRav for ; Wed, 3 Oct 2018 07:04:19 -0700 (PDT) Received: from 8.mo173.mail-out.ovh.net (8.mo173.mail-out.ovh.net [46.105.46.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F3C21312AD for ; Wed, 3 Oct 2018 07:04:18 -0700 (PDT) Received: from player693.ha.ovh.net (unknown [10.109.159.123]) by mo173.mail-out.ovh.net (Postfix) with ESMTP id 89AE7D9533 for ; Wed, 3 Oct 2018 16:04:15 +0200 (CEST) Received: from [10.41.51.103] (134.163-14-84.ripe.coltfrance.com [84.14.163.134]) (Authenticated sender: contact@simonbernard.eu) by player693.ha.ovh.net (Postfix) with ESMTPSA id 5115A4400D2 for ; Wed, 3 Oct 2018 16:04:14 +0200 (CEST) To: "tls@ietf.org" From: Simon Bernard Message-ID: <6bab54cd-e903-ac3e-a186-077458a2d652@simonbernard.eu> Date: Wed, 3 Oct 2018 16:04:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Ovh-Tracer-Id: 14726489307834956017 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrtddvgdejhecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecu Archived-At: Subject: [TLS] HELLO_VERIFY_REQUEST during abbreviated handshake (session resumption) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 14:04:21 -0000 Hi,    In DTLS 1.2 over UDP, I would like to know what is the recommendation about using HELLO_VERIFY_REQUEST during an abbreviated handshake.    Should we send it all the time ? or could we avoid to send it if SESSION ID is known ? Thx, Simon From nobody Wed Oct 3 08:29:32 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0761312C5 for ; Wed, 3 Oct 2018 08:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpGQoWxgMXGR for ; Wed, 3 Oct 2018 08:29:28 -0700 (PDT) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6E241312E7 for ; Wed, 3 Oct 2018 08:29:28 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id n6-v6so6370738qtl.4 for ; Wed, 03 Oct 2018 08:29:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uxkoYJBXPTMX9on6al5b23zj75J4L1k4tUFNQxEFVPw=; b=A+p4GXizpMCmHHHHfVkP9yvJC3yz6W3RgoR159QDJOOMHFpZvaTybObf5UW0qVmDBv KKmHi/StaHgY0SuYSdnSzernqVqV33Yh4AOsN+00B17oD3OzIB4GWdx85X9RXEAAW9Q2 1nZZ9k/HjBOO0w4Rvt4YejnAuwyAfpiIC0yOI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uxkoYJBXPTMX9on6al5b23zj75J4L1k4tUFNQxEFVPw=; b=lJkDoV+HBgUdw9Znr7Oacjbguq8ruRVdyGpcsKTRI2bZk7apw7svXgrvSlsBwGZMjT fhldxWZg1NgaJYmk5NESuAyVRX/n0YFlkTakTmY3dG0Ux4aWtmgJs/Y7Yc92Lnh7Pf3G 9Vdfrlz5Uo0EARmNyXD4BYljqjZIX2pLcM5RiEuSeYqJ0YhHdr3rXxjkoe+1ta4XONcJ jW074AZkYd5MpvMaQNLHVMq7P3FhlcGybOqCNK8+QMxG8UAVGE5s3o/ZsFmfjxFIoxsh rHVqorS3iuMYMgvnY64jJfHE25RxBCdTM4CIDjZ1MWrY5k99yNQXLZDBEXrl8UOh5rWW EVSA== X-Gm-Message-State: ABuFfojYB9hKY9ppSerzTEOAHXgkA2KAQVnlYfqirhAgsBgPt7cqkJs3 9FSaBlkyVrRYcap9bUDL0mOYndzqrNk= X-Google-Smtp-Source: ACcGV62fFOaf5khcL/s/FYU8icYtSZrWDd0XB7izscFCkYC7ctuLSXYLX7sX+va3An5ZjVBALLlIBQ== X-Received: by 2002:a05:6214:114e:: with SMTP id b14mr1624104qvt.169.1538580567870; Wed, 03 Oct 2018 08:29:27 -0700 (PDT) Received: from [172.16.0.18] ([96.231.224.191]) by smtp.gmail.com with ESMTPSA id k185-v6sm739042qkd.27.2018.10.03.08.29.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Oct 2018 08:29:25 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sean Turner In-Reply-To: <1538547426940.37433@cs.auckland.ac.nz> Date: Wed, 3 Oct 2018 11:29:23 -0400 Cc: Benjamin Kaduk , tls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <1534764197914.55986@cs.auckland.ac.nz> <1537900287727.4977@cs.auckland.ac.nz> <20180925184219.GD19845@akamai.com> <20181002141336.GN19845@akamai.com> <1538547426940.37433@cs.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [TLS] Request to register value in TLS extension registry X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 15:29:31 -0000 > On Oct 3, 2018, at 02:17, Peter Gutmann = wrote: >=20 > [CC'd back to the TLS list because this affects other TLS work as = well] >=20 > Benjamin Kaduk writes: >=20 >> Having looked a bit harder, it seems that perhaps I need to point out = that, >> if you want IANA to allocate a value, you need to *ask IANA for it*. = The >> tls-reg-review@ietf.org list is not a supported IANA entrypoint; >=20 > That's not what the RFC appears to say: >=20 > Specification Required [RFC8126] registry requests are registered > after a three-week review period on the > mailing list, on the advice of one or more designated experts. >=20 > [...] >=20 > Registration requests sent to the mailing list for review SHOULD use > an appropriate subject (e.g., "Request to register value in TLS bar > registry"). >=20 > This is exactly what I did, I sent a registration request to the list = for > review. >=20 > Within the review period, the designated experts will either approve > or deny the registration request, communicating this decision to the > review list and IANA. >=20 > This never happened. >=20 > Did anyone actually test RFC 8447 before it was published? You are the first. > You send a request > to a mailing list that doesn't seem to work, to be reviewed by a = secret panel > (well, we know that Rich Salz is one member :-), with no public = discussion or > list archives you can examine to see what happened, and in my case no = response > to the registration request submitted as per the RFC. The =E2=80=9Cpanel=E2=80=9D is not secret. The experts were identified = when draft-ietf-tls-tls13 and draft-ietf-tls-iana-registry-updates were = approved [0][1] and are/were enshrined in the IANA registry [2][3]. We are in the process of changing the archives to be public accessible. Since you have been squatting on a code point for a bit [4], I am hoping = that you can bear with us while we work the kinks out. spt [0] https://www.ietf.org/mail-archive/web/tls/current/msg25837.html [1] https://www.ietf.org/mail-archive/web/tls/current/msg26316.html [2] = https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontyp= e-values.xhtml [3] https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml [4] = https://mailarchive.ietf.org/arch/msg/tls/rxIiS3pn63yp9YaZMODWXCk8mTg= From nobody Wed Oct 3 09:28:48 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA1D1312F6; Wed, 3 Oct 2018 09:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bokLTHsvpx28; Wed, 3 Oct 2018 09:28:45 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C52B9131307; Wed, 3 Oct 2018 09:28:45 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w93GRGHr000576; Wed, 3 Oct 2018 17:28:14 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=Xbm2cpnulvMqxZjIKjuYbyc95Jkl7MRPWjfd2E2NirU=; b=ie2zpgtlRDQUc5gjOkQ+BWb+S1+fkOZYxN9vmjX2DBXpqxe7WOqTSHMEIjwx0E30OFW/ Nk+4VsGBn6dl/A85tZigFSheVVay/bUUJj8dqGGy/TwHC1aeYd6P+JSQbEFMamt0i7MU 6nkSXUSsKYZsYOJzF772Tk0+rV8alqw5jOK3cxGs9Pan501bGofi+QpwNopT5dP4rA73 D8SQJdih+uj8KUw5wtJ3Z0pEjtKCzFXgsA9566mk3sFgziAqmtS5Dh4dyE0nCPeMvr2n nPDc3vYsn/y6ksq1/jDKO7VU6NjDFpT/DTGf1bODCiSjKrVBVqfI8HpHzBNYF2AxNvcv fA== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0a-00190b01.pphosted.com with ESMTP id 2mvgu2tp5w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 03 Oct 2018 17:28:14 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w93GKEUZ018459; Wed, 3 Oct 2018 12:28:13 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint1.akamai.com with ESMTP id 2mt4raufeg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 03 Oct 2018 12:28:13 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 3 Oct 2018 12:28:12 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1365.000; Wed, 3 Oct 2018 12:28:12 -0400 From: "Salz, Rich" To: Peter Gutmann , "tls-reg-review@ietf.org" , "tls@ietf.org" , "iana@iana.org" Thread-Topic: [TLS] Request to register value in TLS extension registry Thread-Index: AQHUWzYTgYCzmvnTw0+jhiJlS3ncUg== Date: Wed, 3 Oct 2018 16:28:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.11.0.180909 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.126] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-03_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810030155 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-03_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810030156 Archived-At: Subject: Re: [TLS] Request to register value in TLS extension registry X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 16:28:47 -0000 WW9hdiBhbmQgSSAodHdvIG9mIHRoZSB0aHJlZSBkZXNpZ25hdGVkIGV4cGVydHMpIGFwcHJvdmUg dGhlIGFzc2lnbm1lbnQgb2YgMjYgZm9yIFRMUy1MVFMuDQoNClNvcnJ5IGZvciB0aGUgZGVsYXlz IGluIGdldHRpbmcgdGhlIHdvcmtmbG93IHdvcmtlZCBvdXQsIFBldGVyLg0KDQoNCu+7v09uIDkv MjUvMTgsIDI6MzIgUE0sICJQZXRlciBHdXRtYW5uIiA8cGd1dDAwMUBjcy5hdWNrbGFuZC5hYy5u ej4gd3JvdGU6DQoNCiAgICA+Tm93IHRoYXQgUkZDIDg0NDcgaXMgcHVibGlzaGVkLCBJJ2QgbGlr ZSB0byByZXF1ZXN0IHRoZSBhZGRpdGlvbiBvZiBleHRlbnNpb24NCiAgICA+SUQgMjYgZm9yIFRM Uy1MVFM6DQogICAgPg0KICAgID5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1ndXRtYW5uLXRscy1sdHMvDQogICAgPg0KICAgID5UaGlzIGV4dGVuc2lvbiBoYXMgYmVlbiB3 YWl0aW5nIGZvciBxdWl0ZSBzb21lIHRpbWUgZm9yIHRoZSBwdWJsaWNhdGlvbiBvZg0KICAgID44 NDQ3LCBzbyBpdCdzIGFscmVhZHkgaW4gdXNlIGJ5IGltcGxlbWVudGF0aW9ucy4NCiAgICANCiAg ICBBcyBwZXIgUkZDIDg0NDcsIEkgcmVxdWVzdGVkIGFsbG9jYXRpb24gb2YgZXh0ZW5zaW9uIElE IDI2IGZvciBUTFMtTFRTIG9uIDIwDQogICAgQXVndXN0LiBUaGUgUkZDIHNheXM6DQogICAgDQog ICAgU3BlY2lmaWNhdGlvbiBSZXF1aXJlZCBbUkZDODEyNl0gcmVnaXN0cnkgcmVxdWVzdHMgYXJl IHJlZ2lzdGVyZWQgYWZ0ZXIgYQ0KICAgIHRocmVlLXdlZWsgcmV2aWV3IHBlcmlvZA0KICAgIA0K ICAgIEl0J3Mgbm93IGJlZW4gbW9yZSB0aGFuIHRoZSB0aHJlZSB3ZWVrcyBsaXN0ZWQgaW4gdGhl IFJGQywgd2hhdCBoYXBwZW5zIG5vdz8NCiAgICBDYW4gSSBsaXN0IHRoZSBleHRlbnNpb24gYXMg YWxsb2NhdGVkIGluIHRoZSBMVFMgZHJhZnQ/DQogICAgDQogICAgUGV0ZXIuDQogICAgDQoNCg== From nobody Wed Oct 3 10:15:30 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB16E127133 for ; Wed, 3 Oct 2018 10:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8tuyQU2WsZY for ; Wed, 3 Oct 2018 10:15:26 -0700 (PDT) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61809127148 for ; Wed, 3 Oct 2018 10:15:26 -0700 (PDT) Received: by mail-qt1-x834.google.com with SMTP id x23-v6so6793748qtr.1 for ; Wed, 03 Oct 2018 10:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=RZZH9AU6pgoCA84vlYpRd5pxz1vdYwUbmy+3DU3Ev/0=; b=VADqk7GNsaEjJs8zGVEPpQdppHD57ytdiDP6jLzjkh0bw02T1JgxojygEpYzSIR6IY bx76i1+U5+AD74bkhTcvoDmPovahPK5ZJ0QDLh/6mXQLWeV/1YnW5rlXALAGNX+GY+aW yXbehQX10apqO+D5Y8wt7nppFO5WBa05DpzlM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=RZZH9AU6pgoCA84vlYpRd5pxz1vdYwUbmy+3DU3Ev/0=; b=m4xHeYi9jKCXQQRb/1JvgCGiI0Lq2vqjp60QSSckz5yYu4VOgkAnFVEACxnhdu4F51 MnotvYtPXVEV2593AGMQhylaZcCl5HwdwLXhw+K+tpbOG/HjHB3AECy+gC3uX1E8EmAf HWmtNmuizAjErCR33SjJq3ydEVgGDj2ZHjI9V+UxoYtU2mnuswVc9AAdWyGgXR2ukO9y cMQmocPIHv5Pq/Ts1+9BuiC0aQMJdqLS5m7zWcea2FNnZVv1nNZB465zNvtM/I5Wq+OK FE3QiaadTB1H5EoCP7ALM5QvWaeEA7THvbEzT8Fho/V0Ilbdo2cRmam8KsB6xPlFi9LL pSHg== X-Gm-Message-State: ABuFfoh+flarTgTBtgb9ORYf53wTxNttGDLtZyfxbbfcGiKeTCe+AtWe X2C9dYsHCerTd+lQ/YoTlNM+R4/4i8A= X-Google-Smtp-Source: ACcGV62a2PqiYi5X7BBP+USa21QQnsz8EtTghdFgy7DxM4TH3IDzJHVtgHYwFIfYKuXzD0A32UHrIw== X-Received: by 2002:a0c:ba9f:: with SMTP id x31-v6mr2006111qvf.126.1538586925294; Wed, 03 Oct 2018 10:15:25 -0700 (PDT) Received: from [172.16.0.18] ([96.231.224.191]) by smtp.gmail.com with ESMTPSA id z3-v6sm833444qkc.55.2018.10.03.10.15.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Oct 2018 10:15:24 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 3 Oct 2018 13:15:22 -0400 References: <153856977342.9010.10521757586695280@ietfa.amsl.com> <20181003123643.GA5454@mandy.flat11.house> To: tls@ietf.org, Alessandro Ghedini In-Reply-To: <20181003123643.GA5454@mandy.flat11.house> Message-Id: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 17:15:29 -0000 > On Oct 3, 2018, at 08:36, Alessandro Ghedini = wrote: >=20 > On Wed, Oct 03, 2018 at 05:29:33AM -0700, internet-drafts@ietf.org = wrote: >>=20 >> 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. >>=20 >> Title : TLS Certificate Compression >> Authors : Alessandro Ghedini >> Victor Vasiliev >> Filename : draft-ietf-tls-certificate-compression-04.txt >> Pages : 7 >> Date : 2018-10-03 >>=20 >> Abstract: >> In TLS handshakes, certificate chains often take up the majority of >> the bytes transmitted. >>=20 >> This document describes how certificate chains can be compressed to >> reduce the amount of data transmitted and avoid some round trips. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> = https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/ >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-tls-certificate-compression-04 >> = https://datatracker.ietf.org/doc/html/draft-ietf-tls-certificate-compressi= on-04 >>=20 >> A diff from the previous version is available at: >> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-certificate-compression= -04 >=20 > This is just a tiny update with a few small fixes and the addition of = the > early code points assigned by IANA. >=20 > In other news, Chrome landed support for certificate compression in = canary > back in July, and Cloudflare deployed support on its edge servers a = few > weeks ago. >=20 > The data we've seen on the Cloudflare side looks quite promising so = far, > although I haven't had the time to do a full analysis yet. We are = seeing > reductions in certificates sizes between 1.5-2 KB for both ECDSA and = RSA > (meaning a full QUIC packet if not more), with average compressed size > hovering around 2.1-2.4 KB for ECDSA and 2.5-3.5 KB for RSA. >=20 > The only remaining open issue is the potential attack illustrated by = Subodh > a few months ago = https://www.ietf.org/mail-archive/web/tls/current/msg25851.html >=20 >> =46rom the reaction on that mailing list discussion, and from talking = to people > at the last IETF, it seems to me that the attack doesn't appear to = worry people > much and that there isn't much interest in fixing it. Though I thought = I'd > mention it again to see if people have anything to add to it, and see = if we > can agree on whether we should do anything about it. >=20 > Other than that it looks like the draft is in a pretty good shape at = this point, > so it'd be nice to have some additional review, and then see if it can = proceed > to the next step (which I think would be WGLC). Alessandro - thanks for this update. WG - I=E2=80=99d like to echo Alessandro request for reviews. If this = outstanding WG item is not resolved before IETF103 we will discuss the = outstanding issue there, and barring any other major issues we are = planning to WGLC the draft after IETF103. One question: There was some discussion earlier about dictionaries. Are = dictionaries being used in the current deployments? spt= From nobody Wed Oct 3 10:19:57 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72AC127148 for ; Wed, 3 Oct 2018 10:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVNc_MMffuYy for ; Wed, 3 Oct 2018 10:19:53 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A31F31252B7 for ; Wed, 3 Oct 2018 10:19:53 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w93HH9fw006956; Wed, 3 Oct 2018 18:19:50 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=/NC2k1ydDnWvhxcsZraX/b5TO3LV3dBaQgrDw+0GN6c=; b=HlubkuyGd+GiubIZb6CUd51aepF2rRoP+CNi5yU9Tu1tVBncYDkjMGo+muoIO543eD3b Y2vi6ZxSnHpE5TdcM1ham9IjWLAXhOuv6Fhi8Am1jPeqHxsM5SxFr1Bu0ygFSIjgQKLp bU8ccBck4BU6XU6GbGt1VSCjeYhqlYJIhsXXqAgL131ebayfzdlgUO8y85WRl7uLCnex bOfv5HBvA0bIpekKjh1hrVP+bsLgMFbfb87c8423tHF4xU6HnfyWara5mz+/39YIVV/J W57slLIIg+tSJLgySgS+GdO958nAByRkHJ1mJ/vQUd5+wXNeGhKK4qHAZuxk3P1fka5/ /A== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2mvgu2ttrt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 03 Oct 2018 18:19:50 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w93H5GZN007327; Wed, 3 Oct 2018 13:19:48 -0400 Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint2.akamai.com with ESMTP id 2mt4qvbcvx-1; Wed, 03 Oct 2018 13:19:48 -0400 Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 98B652099F; Wed, 3 Oct 2018 17:19:48 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1g7koN-0005Lg-Vn; Wed, 03 Oct 2018 12:19:48 -0500 Date: Wed, 3 Oct 2018 12:19:47 -0500 From: Benjamin Kaduk To: Peter Gutmann Cc: "" Message-ID: <20181003171947.GT19845@akamai.com> References: <1534764197914.55986@cs.auckland.ac.nz> <1537900287727.4977@cs.auckland.ac.nz> <20180925184219.GD19845@akamai.com> <20181002141336.GN19845@akamai.com> <1538547426940.37433@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1538547426940.37433@cs.auckland.ac.nz> User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-03_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810030161 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-03_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810030163 Archived-At: Subject: Re: [TLS] Request to register value in TLS extension registry X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 17:19:56 -0000 On Wed, Oct 03, 2018 at 06:17:09AM +0000, Peter Gutmann wrote: > [CC'd back to the TLS list because this affects other TLS work as well] (I responded privately to Peter about this already.) > Benjamin Kaduk writes: > > >Having looked a bit harder, it seems that perhaps I need to point out that, > >if you want IANA to allocate a value, you need to *ask IANA for it*. The > >tls-reg-review@ietf.org list is not a supported IANA entrypoint; > > That's not what the RFC appears to say: > > Specification Required [RFC8126] registry requests are registered > after a three-week review period on the > mailing list, on the advice of one or more designated experts. > > [...] > > Registration requests sent to the mailing list for review SHOULD use > an appropriate subject (e.g., "Request to register value in TLS bar > registry"). > > This is exactly what I did, I sent a registration request to the list for > review. I'll note that there is a different interpretation of the text of the RFC, namely that it is guidance to IANA, not guidance to those requesting codepoints. (In particular, the IANA Considerations section says that the whole document is IANA considerations.) IANA is the authoritative source for both the numbers in the registries and what the registration procedure is for getting new allocations; they have full-time professional staff to answer questions and an SLA. If you're uncertain of the process, asking them seems like a great plan, rather than assuming you will guess correctly. Interestingly, https://datatracker.ietf.org/list/nonwg only has three other foo-reg-review lists, one of which has something funky happening with the MHonArc archivs. The other two have some pretty sparse traffic, but all successful requests do seem to end with someone actively sending mail to IANA. That is, IANA is not monitoring the list so as to take action. I suppose if you want to count on the kindness and organizational skills of the volunteer experts and have them remember to tell IANA about the end of a review period, you could do that ... or you could tell IANA yourself and be sure that they know. I'll also give some general background that the whole reason we have designated experts is to provide the technical advice that IANA does not have in-house, as needed by certain registration policies. For Standards-Action, the technical expertise is wholly delegated to the IETF; for RFC-Required, the IETF/IAB/ISE. FCFS requires no expertise at all, but Specification-Required and Expert-Review need the experts, to provide guidance to IANA on technical questions. Nonetheless, it's still IANA making the registration, just acting on the advice of the experts. My advice remains: talk to the professionals first. > Within the review period, the designated experts will either approve > or deny the registration request, communicating this decision to the > review list and IANA. > > This never happened. I don't think you actually had enough public data when you sent this to be confident it was true. After all, the experts could have sent the decision to IANA and IANA dropped it on the floor. > Did anyone actually test RFC 8447 before it was published? You send a request > to a mailing list that doesn't seem to work, to be reviewed by a secret panel > (well, we know that Rich Salz is one member :-), with no public discussion or > list archives you can examine to see what happened, and in my case no response > to the registration request submitted as per the RFC. Sean has already clarified much of this. But I'm curious; if you think you have followed the proper procedure, why did you not act on the escalation procedure I pointed out to you previously, rather than continuing to complain on the TLS WG list? -Ben From nobody Wed Oct 3 11:49:30 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E85CC12D7F8 for ; Wed, 3 Oct 2018 11:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ion3XKNnDsj for ; Wed, 3 Oct 2018 11:49:25 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0107.outbound.protection.outlook.com [104.47.41.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71F61129C6A for ; Wed, 3 Oct 2018 11:49:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+C23Zez05CONeEA4y7sUC0cdkHJH2I0SjVetLZDDqws=; b=QeMlm6yz/ZSRut3csFOSPvuCfRt5QgfUn7qglCCZXLPWF1LIuhQq9PxyZMYO01AEAVCWApAmjJvtQLkdKvfF9tjqExvGdOGn2dv/BTKOXWszfm5hJF8nJeNfukcDxywPV0dmF6ur72rBuhOJNX59/d0dbXApyIeStkCzn+fxczc= Received: from CY4PR22MB0983.namprd22.prod.outlook.com (10.171.171.20) by CY4PR22MB0248.namprd22.prod.outlook.com (10.169.187.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.21; Wed, 3 Oct 2018 18:49:22 +0000 Received: from CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::f4f6:67f1:e04e:7f6a]) by CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::f4f6:67f1:e04e:7f6a%5]) with mapi id 15.20.1207.018; Wed, 3 Oct 2018 18:49:21 +0000 From: Mike Bishop To: Sean Turner , Peter Gutmann CC: "tls@ietf.org" Thread-Topic: [TLS] Request to register value in TLS extension registry Thread-Index: AQHUOHgQgYCzmvnTw0+jhiJlS3ncUqUBiyFo//85voCACqR6AIAB5qLVgACazYCAADbSAA== Date: Wed, 3 Oct 2018 18:49:21 +0000 Message-ID: References: <1534764197914.55986@cs.auckland.ac.nz> <1537900287727.4977@cs.auckland.ac.nz> <20180925184219.GD19845@akamai.com> <20181002141336.GN19845@akamai.com> <1538547426940.37433@cs.auckland.ac.nz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR22MB0248; 6:msYKn3Lcxq6nKx3QMLDm0+afkR7vaA7eTvUivhKWZYSY7PJM2CKoTbjdea0tWDlgm7TrhrQ+L9eTWhI6p69jHJ5eF5RM+Wf6wsrm232tqj3uZEKFugUkifh0AZZ3Ts0q56X/O5nHS70u6s8qdMZrVtLPuBAIMWqw8vm4HxHuHzTINtzaORPwCSLZHCDg0tV2FAriKb/d/31sKG+NkRdheza3aRT4Hxc2o6pL9KF4hAkUa0anaVzIyHSaUKMWOSKLg62EHDDW/qwnamzd2jAVeUT5dZXant2zUZJcgM5UWC5rMDuR3N6mM79v4ctkQm5hFeqPkq3wXfCG//TuPteHqLupk0R6xsYmNoFP6a78UXynUIDpsRQ1xeRxeMfoRZmpoy9F1KX8INNkKg0XqAJFyQUfIG2gQCmnKjZEdnM+zscAaQcQ+McwmCi9AyS7Sq5oH/GNmQQXTNWaEnBEHAVsUw==; 5:hLJG6PgebQ4BTB/V0txlqWcxw1d+SK/wI1IyeEDjtzf0IMZo6d6X/q6FQmHUJII4jUD6Qp3GFQNYf+iR1hlAJ9QDf/ksHANf1BQXPHbKT+NUBgV8lnh9Na994NMENrMmcb5PGrrAKvmq6u62kmO20GlpDLnTy2kyB3X9QZKim/w=; 7:gTv5RSQBBBVvgd/OhzdPNWQeY8aiwjwwPM236dZUISEsn2SLm+EaNICrPmg6W33d5bj1PExmX5h0ck1ZhaB8nvwIQtyvndURREZLFiMJdu1RgOa4sIK/NWV3o9lbPHeeu8n9z4hoTvB/RMpb5jvlJdR+nViTVmLIFxJcJycZSnI/ZhWLWUEPOBPBgKW2VgpA5OqClT8qBEg4aNKvyjEmGyBvXMFW3wTwAc+TRzLLqiKzV0LtE9qBMOPZGiUluktp x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: f0cf8c30-09b8-40d4-1053-08d62960eec0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:CY4PR22MB0248; x-ms-traffictypediagnostic: CY4PR22MB0248: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(1591387915157); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231355)(944501410)(52105095)(3002001)(149066)(150057)(6041310)(20161123564045)(20161123562045)(20161123558120)(2016111802025)(20161123560045)(6043046)(201708071742011)(7699051); SRVR:CY4PR22MB0248; BCL:0; PCL:0; RULEID:; SRVR:CY4PR22MB0248; x-forefront-prvs: 0814A2C7A3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(39830400003)(346002)(396003)(136003)(189003)(199004)(13464003)(55016002)(2900100001)(476003)(966005)(68736007)(14454004)(76176011)(8676002)(316002)(14444005)(256004)(6306002)(102836004)(33656002)(5660300001)(9686003)(2906002)(93886005)(486006)(229853002)(6246003)(186003)(305945005)(99286004)(26005)(508600001)(110136005)(74482002)(66066001)(97736004)(74316002)(71190400001)(7736002)(6436002)(446003)(71200400001)(11346002)(8936002)(86362001)(3846002)(6116002)(53546011)(105586002)(6506007)(7696005)(345774005)(4326008)(106356001)(5250100002)(53936002)(25786009)(81156014)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR22MB0248; H:CY4PR22MB0983.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: vCsXDpv3NlJ8uVrm5ZOSTLxSKaFmhyb2ucScDPTusfepQ98qrUOpRZ5tnhgeyP9zRb96Op1PMTbcn8wyFagzIBZyPUVNKWiM727hJQpps5WRJjEpnbHFdrcTvSe6R9btmDrVcdYmr3LFyS/X/Gk7RXTDQRSNbQdE8q9Kwe67hepAfAEP5HvHAdGSwii/WkvUMGZ+n8G1Yl4btsT3Eo3FJB4S5aaaekIakLuHGhiF52TSzN8yvPwuEqQnnfVjwuULULdBA00H+qzvxWiIKrmbJ16n4pj5RtZqgeayphvdXFJzoFlZlI1SUStUbsVahSINqlp8z96KAqw2kpOpdaL8D5NL4HJnZc4O500HbScim8I= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: f0cf8c30-09b8-40d4-1053-08d62960eec0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Oct 2018 18:49:21.7105 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR22MB0248 Archived-At: Subject: Re: [TLS] Request to register value in TLS extension registry X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 18:49:29 -0000 QWN0dWFsbHksIEkgc3VibWl0dGVkIGEgcmVxdWVzdCB0byBJQU5BIHdoaWxlIHRoaXMgUkZDIHdh cyBpbiBwcm9jZXNzIHdoaWNoIGdvdCBzZW50IHRvIHRoZSB0bHMtcmVnLXJldmlldyBhbGlhcyBm b3IgYXBwcm92YWwuICBUaGVyZSB3YXMgYXBwYXJlbnRseSBhIGhpY2N1cCwgd2hlcmUgdGhlIGFs aWFzIG1lbWJlcnMgZGlkIG5vdCByZWNlaXZlIHRoZSByZXF1ZXN0IGZyb20gSUFOQSwgYnV0IGRp ZCByZWNlaXZlIG15IGZvbGxvdy11cCBlLW1haWwgYXNraW5nIGlmIGFueW9uZSBoYWQgbG9va2Vk IGF0IGl0LiAgSUFOQSdzIHVuZGVyc3RhbmRpbmcgb2YgdGhlIG5ldyBwcm9jZXNzIGF0IHRoZSB0 aW1lIHdhczoNCg0KICAgID4+IFRoYW5rIHlvdSBmb3IgY29udGFjdGluZyB1cy4gV2UndmUgc2Vu dCB0aGlzIG9uIHRvIHRoZSBuZXcgdGVhbSBvZg0KICAgID4+IElFU0ctZGVzaWduYXRlZCBleHBl cnRzLiBUaGUgQXBwbGljYXRpb24tTGF5ZXIgUHJvdG9jb2wgTmVnb3RpYXRpb24NCiAgICA+PiAo QUxQTikgUHJvdG9jb2wgSURzIHJlZ2lzdHJ5IHdpbGwgYmUgdXBkYXRlZCBzb29uIHRvIGluY2x1 ZGUgYSBsaW5rIHRvDQogICAgPj4gcmVjZW50bHktYXBwcm92ZWQgZG9jdW1lbnQgZHJhZnQtaWV0 Zi10bHMtaWFuYS1yZWdpc3RyeS11cGRhdGVzLCB3aGljaA0KICAgID4+IHByb3ZpZGVzIG5ldyBp bnN0cnVjdGlvbnMgZm9yIHN1Ym1pdHRpbmcgcmVnaXN0cmF0aW9uIHJlcXVlc3RzIGZvcg0KICAg ID4+IHNvbWUgb2YgdGhlIFRMUyByZWdpc3RyaWVzLiBTcGVjaWZpY2FsbHksIGluIHRoZSBmdXR1 cmUsIG5ldyByZXF1ZXN0cw0KICAgID4+IHNob3VsZCBiZSBzZW50IHRvIGEgbWFpbGluZyBsaXN0 IChyYXRoZXIgdGhhbiBJQU5BKSBmb3IgYSB0aHJlZS13ZWVrDQogICAgPj4gcmV2aWV3IHBlcmlv ZC4gVGhlIGV4cGVydHMgd2lsbCB0aGVuIGNvbnRhY3QgdXMgaWYgdGhleSBhcHByb3ZlIGENCiAg ICA+PiByZWdpc3RyYXRpb24uDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBU TFMgPHRscy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgU2VhbiBUdXJuZXINClNlbnQ6 IFdlZG5lc2RheSwgT2N0b2JlciAzLCAyMDE4IDg6MjkgQU0NClRvOiBQZXRlciBHdXRtYW5uIDxw Z3V0MDAxQGNzLmF1Y2tsYW5kLmFjLm56Pg0KQ2M6IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtUTFNdIFJlcXVlc3QgdG8gcmVnaXN0ZXIgdmFsdWUgaW4gVExTIGV4dGVuc2lvbiByZWdpc3Ry eQ0KDQoNCg0KPiBPbiBPY3QgMywgMjAxOCwgYXQgMDI6MTcsIFBldGVyIEd1dG1hbm4gPHBndXQw MDFAY3MuYXVja2xhbmQuYWMubno+IHdyb3RlOg0KPiANCj4gW0NDJ2QgYmFjayB0byB0aGUgVExT IGxpc3QgYmVjYXVzZSB0aGlzIGFmZmVjdHMgb3RoZXIgVExTIHdvcmsgYXMgDQo+IHdlbGxdDQo+ IA0KPiBCZW5qYW1pbiBLYWR1ayA8YmthZHVrQGFrYW1haS5jb20+IHdyaXRlczoNCj4gDQo+PiBI YXZpbmcgbG9va2VkIGEgYml0IGhhcmRlciwgaXQgc2VlbXMgdGhhdCBwZXJoYXBzIEkgbmVlZCB0 byBwb2ludCBvdXQgDQo+PiB0aGF0LCBpZiB5b3Ugd2FudCBJQU5BIHRvIGFsbG9jYXRlIGEgdmFs dWUsIHlvdSBuZWVkIHRvICphc2sgSUFOQSBmb3IgDQo+PiBpdCouICBUaGUgdGxzLXJlZy1yZXZp ZXdAaWV0Zi5vcmcgbGlzdCBpcyBub3QgYSBzdXBwb3J0ZWQgSUFOQSANCj4+IGVudHJ5cG9pbnQ7 DQo+IA0KPiBUaGF0J3Mgbm90IHdoYXQgdGhlIFJGQyBhcHBlYXJzIHRvIHNheToNCj4gDQo+ICAg U3BlY2lmaWNhdGlvbiBSZXF1aXJlZCBbUkZDODEyNl0gcmVnaXN0cnkgcmVxdWVzdHMgYXJlIHJl Z2lzdGVyZWQNCj4gICBhZnRlciBhIHRocmVlLXdlZWsgcmV2aWV3IHBlcmlvZCBvbiB0aGUgPHRs cy1yZWctcmV2aWV3QGlldGYub3JnPg0KPiAgIG1haWxpbmcgbGlzdCwgb24gdGhlIGFkdmljZSBv ZiBvbmUgb3IgbW9yZSBkZXNpZ25hdGVkIGV4cGVydHMuDQo+IA0KPiAgIFsuLi5dDQo+IA0KPiAg IFJlZ2lzdHJhdGlvbiByZXF1ZXN0cyBzZW50IHRvIHRoZSBtYWlsaW5nIGxpc3QgZm9yIHJldmll dyBTSE9VTEQgdXNlDQo+ICAgYW4gYXBwcm9wcmlhdGUgc3ViamVjdCAoZS5nLiwgIlJlcXVlc3Qg dG8gcmVnaXN0ZXIgdmFsdWUgaW4gVExTIGJhcg0KPiAgIHJlZ2lzdHJ5IikuDQo+IA0KPiBUaGlz IGlzIGV4YWN0bHkgd2hhdCBJIGRpZCwgSSBzZW50IGEgcmVnaXN0cmF0aW9uIHJlcXVlc3QgdG8g dGhlIGxpc3QgDQo+IGZvciByZXZpZXcuDQo+IA0KPiAgIFdpdGhpbiB0aGUgcmV2aWV3IHBlcmlv ZCwgdGhlIGRlc2lnbmF0ZWQgZXhwZXJ0cyB3aWxsIGVpdGhlciBhcHByb3ZlDQo+ICAgb3IgZGVu eSB0aGUgcmVnaXN0cmF0aW9uIHJlcXVlc3QsIGNvbW11bmljYXRpbmcgdGhpcyBkZWNpc2lvbiB0 byB0aGUNCj4gICByZXZpZXcgbGlzdCBhbmQgSUFOQS4NCj4gDQo+IFRoaXMgbmV2ZXIgaGFwcGVu ZWQuDQo+IA0KPiBEaWQgYW55b25lIGFjdHVhbGx5IHRlc3QgUkZDIDg0NDcgYmVmb3JlIGl0IHdh cyBwdWJsaXNoZWQ/DQoNCllvdSBhcmUgdGhlIGZpcnN0Lg0KDQo+IFlvdSBzZW5kIGEgcmVxdWVz dA0KPiB0byBhIG1haWxpbmcgbGlzdCB0aGF0IGRvZXNuJ3Qgc2VlbSB0byB3b3JrLCB0byBiZSBy ZXZpZXdlZCBieSBhIA0KPiBzZWNyZXQgcGFuZWwgKHdlbGwsIHdlIGtub3cgdGhhdCBSaWNoIFNh bHogaXMgb25lIG1lbWJlciA6LSksIHdpdGggbm8gDQo+IHB1YmxpYyBkaXNjdXNzaW9uIG9yIGxp c3QgYXJjaGl2ZXMgeW91IGNhbiBleGFtaW5lIHRvIHNlZSB3aGF0IA0KPiBoYXBwZW5lZCwgYW5k IGluIG15IGNhc2Ugbm8gcmVzcG9uc2UgdG8gdGhlIHJlZ2lzdHJhdGlvbiByZXF1ZXN0IHN1Ym1p dHRlZCBhcyBwZXIgdGhlIFJGQy4NCg0KVGhlIOKAnHBhbmVs4oCdIGlzIG5vdCBzZWNyZXQuICBU aGUgZXhwZXJ0cyB3ZXJlIGlkZW50aWZpZWQgd2hlbiBkcmFmdC1pZXRmLXRscy10bHMxMyBhbmQg ZHJhZnQtaWV0Zi10bHMtaWFuYS1yZWdpc3RyeS11cGRhdGVzIHdlcmUgYXBwcm92ZWQgWzBdWzFd IGFuZCBhcmUvd2VyZSBlbnNocmluZWQgaW4gdGhlIElBTkEgcmVnaXN0cnkgWzJdWzNdLg0KDQpX ZSBhcmUgaW4gdGhlIHByb2Nlc3Mgb2YgY2hhbmdpbmcgdGhlIGFyY2hpdmVzIHRvIGJlIHB1Ymxp YyBhY2Nlc3NpYmxlLg0KDQpTaW5jZSB5b3UgaGF2ZSBiZWVuIHNxdWF0dGluZyBvbiBhIGNvZGUg cG9pbnQgZm9yIGEgYml0IFs0XSwgSSBhbSBob3BpbmcgdGhhdCB5b3UgY2FuIGJlYXIgd2l0aCB1 cyB3aGlsZSB3ZSB3b3JrIHRoZSBraW5rcyBvdXQuDQoNCnNwdA0KDQpbMF0gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi90bHMvY3VycmVudC9tc2cyNTgzNy5odG1sDQpbMV0g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi90bHMvY3VycmVudC9tc2cyNjMx Ni5odG1sDQpbMl0gaHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvdGxzLWV4dGVuc2lv bnR5cGUtdmFsdWVzL3Rscy1leHRlbnNpb250eXBlLXZhbHVlcy54aHRtbA0KWzNdIGh0dHBzOi8v d3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3Rscy1wYXJhbWV0ZXJzL3Rscy1wYXJhbWV0ZXJzLnho dG1sDQpbNF0gaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy90bHMvcnhJaVMz cG42M3lwOVlhWk1PRFdYQ2s4bVRnDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KVExTIG1haWxpbmcgbGlzdA0KVExTQGlldGYub3JnDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0K From nobody Wed Oct 3 11:52:30 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490DB129C6A; Wed, 3 Oct 2018 11:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDtmmxy1GWd0; Wed, 3 Oct 2018 11:52:25 -0700 (PDT) Received: from smtp01.icann.org (smtp01.icann.org [192.0.46.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3818F1294D0; Wed, 3 Oct 2018 11:52:25 -0700 (PDT) Received: from request4.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp01.icann.org (Postfix) with ESMTP id 73865E097B; Wed, 3 Oct 2018 18:52:24 +0000 (UTC) Received: by request4.lax.icann.org (Postfix, from userid 48) id 3A6F5209B9; Wed, 3 Oct 2018 18:52:24 +0000 (UTC) RT-Owner: amanda.baber From: "Amanda Baber via RT" Reply-To: iana-prot-param@iana.org In-Reply-To: References: Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #1125916 X-Managed-BY: RT 4.4.3 (http://www.bestpractical.com/rt/) X-RT-Originator: amanda.baber@icann.org To: rsalz@akamai.com CC: tls@ietf.org, tls-reg-review@ietf.org, pgut001@cs.auckland.ac.nz Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Wed, 03 Oct 2018 18:52:24 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [TLS] [IANA #1125916] Re: Request to register value in TLS extension registry X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2018 18:52:27 -0000 Hi all, We've registered the following TLS ExtensionType Value: Value: 26 Extension Name: tls_lts TLS 1/3: - Recommended: N Reference: [draft-gutmann-tls-lts] Please see https://www.iana.org/assignments/tls-extensiontype-values Our preference is that the contents of the "TLS 1.3" and "Recommended" fields be added to the IANA Considerations section. Best regards, Amanda Baber Lead IANA Services Specialist On Wed Oct 03 16:28:46 2018, rsalz@akamai.com wrote: > Yoav and I (two of the three designated experts) approve the > assignment of 26 for TLS-LTS. > > Sorry for the delays in getting the workflow worked out, Peter. > > > On 9/25/18, 2:32 PM, "Peter Gutmann" > wrote: > > > Now that RFC 8447 is published, I'd like to request the addition of > > extension > > ID 26 for TLS-LTS: > > > > https://datatracker.ietf.org/doc/draft-gutmann-tls-lts/ > > > > This extension has been waiting for quite some time for the > > publication of > > 8447, so it's already in use by implementations. > > As per RFC 8447, I requested allocation of extension ID 26 for TLS-LTS > on 20 > August. The RFC says: > > Specification Required [RFC8126] registry requests are registered > after a > three-week review period > > It's now been more than the three weeks listed in the RFC, what > happens now? > Can I list the extension as allocated in the LTS draft? > > Peter. > > From nobody Wed Oct 3 19:52:04 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53BB6130DD6 for ; Wed, 3 Oct 2018 19:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkBPTknORgig for ; Wed, 3 Oct 2018 19:51:58 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 018ED130DD5 for ; Wed, 3 Oct 2018 19:51:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1538621518; x=1570157518; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MdQI3zi5jcZBtCrh7l6K/4JuR6hsq6Hv0w2mXauQr6g=; b=Vw8h6fQEE8JFye2kvS4yUUgJSogUCdfp0Q4Dwd8GSK6pLvD4LNwWEa9Z gDPEgJ6LKejT12fbJ+9zba+S/rkRdbEzQLKubmg7y6EiGuLYPWu2K2SA3 e558zQEc9qBL3KEybjRnYwDljI8CYWPpYM+nYqT4fNrFjdz0gS1Q5tJqO I0aRdHiI55YJnntzeASy88HdzetW5riYaBB2mAoqdqOitGUf80TCgUZus HTnsXlFZQFGokss0n8Rmu7LdSA72929z+Q/xKZjXxJnZG0ebB89IUL/gd /b9MXfBuwc6DNuCTkgtJwW4hcJl320ujlhMXkoXziF+WYU+nvWIERQd1C A==; X-IronPort-AV: E=Sophos;i="5.54,338,1534766400"; d="scan'208";a="33521737" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.3 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-b.UoA.auckland.ac.nz) ([10.6.3.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 04 Oct 2018 15:51:52 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-b.UoA.auckland.ac.nz (10.6.3.3) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 4 Oct 2018 15:51:52 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Thu, 4 Oct 2018 15:51:52 +1300 From: Peter Gutmann To: Sean Turner CC: Benjamin Kaduk , "tls@ietf.org" Thread-Topic: [TLS] Request to register value in TLS extension registry Thread-Index: AQHUOHgQgYCzmvnTw0+jhiJlS3ncUqUBiyFo//85voCACqR6AIAB5qLV///A34CAAZhzpg== Date: Thu, 4 Oct 2018 02:51:51 +0000 Message-ID: <1538621511659.33028@cs.auckland.ac.nz> References: <1534764197914.55986@cs.auckland.ac.nz> <1537900287727.4977@cs.auckland.ac.nz> <20180925184219.GD19845@akamai.com> <20181002141336.GN19845@akamai.com> <1538547426940.37433@cs.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Request to register value in TLS extension registry X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 02:52:02 -0000 Sean Turner writes:=0A= =0A= >The =93panel=94 is not secret. The experts were identified when =0A= >draft-ietf-tls-tls13 and draft-ietf-tls-iana-registry-updates were =0A= >approved [0][1] and are/were enshrined in the IANA registry [2][3].=0A= =0A= Ah, OK. When I checked, the membership of tls-reg-review@ietf.org=0A= was listed as private... the whole process seemed rather opaque=0A= (e.g. no public discussion or list archives), which was why I cc'd =0A= it to the main TLS list, to give anyone who wanted to add their =0A= $0.10 a chance.=0A= =0A= >We are in the process of changing the archives to be public =0A= >accessible.=0A= =0A= Thanks! I wasn't sure if the non-public nature was deliberate or=0A= a configuration error.=0A= =0A= Peter.=0A= From nobody Wed Oct 3 19:56:07 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D83F130DD8; Wed, 3 Oct 2018 19:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTceyTh3-Qu7; Wed, 3 Oct 2018 19:56:04 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C3E7130DD5; Wed, 3 Oct 2018 19:56:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1538621764; x=1570157764; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=WrmSX6RcB2CeZbuqRM7itG4PcKC8sdYmGvtbfrXJ+x0=; b=tyETko0l/s322hCKcrB6Jt9R9CvZOfAyaFwQ+1jXDU+reG8iTmV6johu T5wdb7I3IgHO+sL/8zGqUCyQR85o51cixEmEyQqmYL+FKaEinyxbvgJj8 fF0WHupSjDBkNz4bGQyqoegq976w6sWfPXEYzuamjDHo3CVA9bRLDJY46 Mx4rN5oqLVKfacfuZFYEqhiWGUUFmfUoAyOHP9/7H2ighWICtPgjlGYYA b5kyrQOxc8mRUk79+6Tg0Vk5nlCYqhkYFB0Kx6q1aNk6bQU0OjaQL2Q6G te/DlKJ1gNE94tHR4A8oCXvHkUHxFSj+uOFUDVlIfmCWmtFiclOHSJ2wC Q==; X-IronPort-AV: E=Sophos;i="5.54,338,1534766400"; d="scan'208";a="33522642" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.9 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-e.UoA.auckland.ac.nz) ([10.6.3.9]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 04 Oct 2018 15:56:01 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-e.UoA.auckland.ac.nz (10.6.3.9) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 4 Oct 2018 15:56:00 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Thu, 4 Oct 2018 15:56:00 +1300 From: Peter Gutmann To: "Salz, Rich" , "tls-reg-review@ietf.org" , "tls@ietf.org" , "iana@iana.org" Thread-Topic: [TLS] Request to register value in TLS extension registry Thread-Index: AQHUWzYTgYCzmvnTw0+jhiJlS3ncUqUOZRr4 Date: Thu, 4 Oct 2018 02:56:00 +0000 Message-ID: <1538621760239.76173@cs.auckland.ac.nz> References: In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Request to register value in TLS extension registry X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 02:56:05 -0000 Salz, Rich writes:=0A= =0A= >Sorry for the delays in getting the workflow worked out, Peter.=0A= =0A= No problem, someone had to be the beta tester :-).=0A= =0A= Peter.=0A= From nobody Wed Oct 3 20:18:37 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EECB130DD5 for ; Wed, 3 Oct 2018 20:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-vwFsuVueC2 for ; Wed, 3 Oct 2018 20:18:34 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65754130DD6 for ; Wed, 3 Oct 2018 20:18:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1538623114; x=1570159114; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=6H69mtBF1phK1/VpSrvFwyjhxemwAoKa6hYo4SBoj38=; b=Fwd7PXy5POUi4uQch8UwhXLlgSlhzmZnzxiPwY2RbhdMWFHgMHvax2UR eNf0pN+tThHt+TGKFr8Q547jafve6id+ycCUXJUzOs60vvp60BShGX+2z IaQkTtcRXOUAw1EEX/B8nPlJA8B/CFgK918vFrbU5kx9EINN/L34LiApK 3seyK31xxmzNIIyCEeG+kQ+cdPlSRTDR52yp6SWDo9bRM8IXISlrXdeKT QFJnTPct+aTFNByfAm5jGvFjPHYA1OZTWdK2Ogjnq+CrRLubu3Hw/+77R ffPpQy6RW2sPg7t0EoBYnl06P8DwMv0KoKjDmabs3Ren1cOM+xmdkV3Ez g==; X-IronPort-AV: E=Sophos;i="5.54,338,1534766400"; d="scan'208";a="33526659" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.4 - Outgoing - Outgoing Received: from uxcn13-tdc-c.uoa.auckland.ac.nz ([10.6.3.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 04 Oct 2018 16:18:32 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-c.UoA.auckland.ac.nz (10.6.3.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 4 Oct 2018 16:18:32 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Thu, 4 Oct 2018 16:18:31 +1300 From: Peter Gutmann To: Benjamin Kaduk CC: "" Thread-Topic: [TLS] Request to register value in TLS extension registry Thread-Index: AQHUOHgQgYCzmvnTw0+jhiJlS3ncUqUBiyFo//85voCACqR6AIAB5qLV///fuICAAYC9UQ== Date: Thu, 4 Oct 2018 03:18:31 +0000 Message-ID: <1538623111690.89938@cs.auckland.ac.nz> References: <1534764197914.55986@cs.auckland.ac.nz> <1537900287727.4977@cs.auckland.ac.nz> <20180925184219.GD19845@akamai.com> <20181002141336.GN19845@akamai.com> <1538547426940.37433@cs.auckland.ac.nz>,<20181003171947.GT19845@akamai.com> In-Reply-To: <20181003171947.GT19845@akamai.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Request to register value in TLS extension registry X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 03:18:36 -0000 Benjamin Kaduk writes:=0A= =0A= >if you think you have followed the proper procedure, why did you not act o= n =0A= >the escalation procedure I pointed out to you previously, rather than =0A= >continuing to complain on the TLS WG list?=0A= =0A= Because I wanted to get it fixed for others who may be going down the same = =0A= path in the future, not just myself. I could have also directly contacted= =0A= people to try and get it resolved, but that wouldn't help the next person= =0A= who's faced with the same issue. Thus my attempt to try and point out =0A= problems so they can be cleared up for others in the future.=0A= =0A= Peter.=0A= From nobody Thu Oct 4 02:02:18 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B21B130E01 for ; Thu, 4 Oct 2018 02:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=telecom-paristech.fr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDlVvG69Q16c for ; Thu, 4 Oct 2018 02:02:13 -0700 (PDT) Received: from zproxy110.enst.fr (zproxy110.enst.fr [IPv6:2001:660:330f:2::c0]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C0A0130E03 for ; Thu, 4 Oct 2018 02:02:12 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by zproxy110.enst.fr (Postfix) with ESMTP id 5240780A53; Thu, 4 Oct 2018 11:02:11 +0200 (CEST) Received: from zproxy110.enst.fr ([IPv6:::1]) by localhost (zproxy110.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id vO2sX1pdN3WB; Thu, 4 Oct 2018 11:02:10 +0200 (CEST) Received: from localhost (localhost [IPv6:::1]) by zproxy110.enst.fr (Postfix) with ESMTP id A997F80BFB; Thu, 4 Oct 2018 11:02:10 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.10.3 zproxy110.enst.fr A997F80BFB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telecom-paristech.fr; s=A6AEC2EE-1106-11E5-B10E-D103FDDA8F2E; t=1538643730; bh=EsJTL1UxuFhTeegWXZ5Vbb8zCOwACxiD71p9bKgeark=; h=Date:From:To:Message-ID:MIME-Version; b=3C8qHev0XIlqRw6ZIf168Wq7O1PAgQOukN4tAJ7g/W3Fa35K1M2Smy4d+DhLnYXwE 5ps5hot1KbBqAlaW+akZw5IBx3Yx4Mtk3UP8te8wFs1FyX6KWbdh/+Y7I8TG2CEJ8a 43nOKrA/0e8EhXXzwakAPRZ8OLt6j9ipcIFwU+G4= X-Virus-Scanned: amavisd-new at zproxy110.enst.fr Received: from zproxy110.enst.fr ([IPv6:::1]) by localhost (zproxy110.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id sqwbQZf6T0pD; Thu, 4 Oct 2018 11:02:10 +0200 (CEST) Received: from zmail112.enst.fr (zmail112.enst.fr [137.194.2.205]) by zproxy110.enst.fr (Postfix) with ESMTP id 84BE980178; Thu, 4 Oct 2018 11:02:10 +0200 (CEST) Date: Thu, 4 Oct 2018 11:02:10 +0200 (CEST) From: Mounira Msahli To: housley Cc: tls Message-ID: <270275274.21760813.1538643729973.JavaMail.zimbra@enst.fr> In-Reply-To: References: <1231917830.3727154.1535119783361.JavaMail.zimbra@enst.fr> <20180827163405.GA19628@LK-Perkele-VII> <235113009.594519.1535390674699.JavaMail.zimbra@enst.fr> <6170599.o3dyPvx8Gh@pintsize.usersys.redhat.com> <1379020500.16565707.1537977448089.JavaMail.zimbra@enst.fr> <20180926192916.GA31766@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [2001:660:330f:cc:f9c7:bf8d:8c3b:8542] X-Mailer: Zimbra 8.8.9_GA_3019 (ZimbraWebClient - FF62 (Linux)/8.8.9_GA_3019) Thread-Topic: TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates Thread-Index: JdEkPsMXvJZ7ZXj6AGsprNDJZK3SfA== Archived-At: Subject: Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 09:02:16 -0000 Thank you Rus,=20 I will correct it.=20 Mounira ----- Mail original ----- De: "housley" =C3=80: "Mounira Msahli" Cc: "tls" Envoy=C3=A9: Mardi 2 Octobre 2018 11:23:07 Objet: Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609= .2 certificates The document says:=20 /* Managed by IANA */=20 enum {=20 X509(0),=20 RawPublicKey(2),=20 1609Dot2(?), /* Number 3 will be requested for 1609.2 */=20 (255)=20 103097(?), /* Number 4 will be requested for 103097 */=20 (255)=20 } CertificateType;=20 Two things...=20 1) The "(255)" should only appear at the end. The one in the middle should = go away.=20 2) Don't the requested additions need to begin with letters?=20 IEEE1609Dot2(?), /* Number 3 will be requested for IEEE 1609.2 */=20 ETSI103097(?), /* Number 4 will be requested for ETSI TS 103 097 */=20 Russ=20 From nobody Thu Oct 4 08:23:01 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74CC7130E61 for ; Thu, 4 Oct 2018 08:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.344 X-Spam-Level: X-Spam-Status: No, score=-0.344 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwzfEtffA5J0 for ; Thu, 4 Oct 2018 08:22:58 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id E752D130E5E for ; Thu, 4 Oct 2018 08:22:57 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id 6B06F3740F88 for ; Thu, 4 Oct 2018 15:22:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at katezarealty.com Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QMAYePZZj_Ij for ; Thu, 4 Oct 2018 11:22:56 -0400 (EDT) Received: from Maxs-MBP.cablelabs.com (unknown [192.160.73.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 66AED37402AF for ; Thu, 4 Oct 2018 11:22:56 -0400 (EDT) To: TLS WG From: "Dr. Pala" Organization: OpenCA Labs Message-ID: <90b6138b-acf9-0836-79e8-556c81d1029a@openca.org> Date: Thu, 4 Oct 2018 09:22:55 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070001060004000500000706" Archived-At: Subject: [TLS] How to Validate Servers' Identities w/out reliable source of time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 15:23:00 -0000 This is a cryptographically signed message in MIME format. --------------ms070001060004000500000706 Content-Type: multipart/alternative; boundary="------------1D382C6811E9B0B04312BDF0" Content-Language: en-US This is a multi-part message in MIME format. --------------1D382C6811E9B0B04312BDF0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi all, I am struggling with one issue that we have been seeing more and more=20 often with the introduction of small IoT devices that connect to clouds=20 via TLS and need to validate the cloud server's (or the other party's)=20 certificate chain. In particular, the problem is that without a reliable (or trusted)=20 source of Time information, devices can not reliably validate=20 certificates (i.e., is the certificate even valid... ? is it expired ?=20 is the revocation info fresh enough ?) and my question for the list is=20 about best practices in the space. The problem is even more problematic=20 for devices with limited access to the network (e.g., access only to=20 specific servers / cloud services) since no "external" source of time=20 can be used. Do you know if there are indications / best practices from ITU or from=20 IETF (or other organizations) on how to deal with this issue ? Has the=20 issue been addressed somewhere ? Cheers, Max --=20 Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------1D382C6811E9B0B04312BDF0 Content-Type: multipart/related; boundary="------------727708929A3EC7196DF9C8A4" --------------727708929A3EC7196DF9C8A4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi all,

I am struggling with one issue that we have been seeing more and more often with the introduction of small IoT devices that connect to clouds via TLS and need to validate the cloud server's (or the other party's) certificate chain.

In particular, the problem is that without a reliable (or trusted) source of Time information, devices can not reliably validate certificates (i.e., is the certificate even valid... ? is it expired ? is the revocation info fresh enough ?) and my question for the list is about best practices in the space. The problem is even more problematic for devices with limited access to the network (e.g., access only to specific servers / cloud services) since no "external" source of time can be used.

Do you know if there are indications / best practices from ITU or from IETF (or other organizations) on how to deal with this issue ? Has the issue been addressed somewhere ?

Cheers,
Max

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
3D"OpenCA
--------------727708929A3EC7196DF9C8A4 Content-Type: image/png; name="dgalblpmlpnnijcm.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="dgalblpmlpnnijcm.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------727708929A3EC7196DF9C8A4-- --------------1D382C6811E9B0B04312BDF0-- --------------ms070001060004000500000706 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CyAwggUyMIIEGqADAgECAhEAu2YCW4tRQdGHMc0S/FQsNDANBgkqhkiG9w0BAQsFADCBlzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0Eg Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTcxMjAxMDAw MDAwWhcNMTgxMjAxMjM1OTU5WjAkMSIwIAYJKoZIhvcNAQkBFhNkaXJlY3RvckBvcGVuY2Eu b3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyEDKYfy+DFhtDn8bIXyP25Xe DjUIkMQDm90A1JPoQ4tuTk6kXwulPvAmvtLGuRAzEqFpV/fqz4sAlx8FgxvRZ5PunZ1H1/lJ CNEdir53Xv8TEf+R/n+Ca5RNUR+GhS72zhp9xx8uDRZds2DeXvW9uhYp9nsbX6rWIFT5YfWF 1SukFXwXSnHuXc9nDT6p0Kp6UNzusn/lMhXhIwgpNA26/mHAdScYyMoB4yaZeMpdZN75XGWO slhXcXdeGJo93E48kffdu0yo4WTbpLwhs/IrkG4OXB1N3Bf+9oHZwVun1hlCZEfuSit0mvrx x8wzPCPiggXu6j6VqPoJqecV6xKCHwIDAQABo4IB6TCCAeUwHwYDVR0jBBgwFoAUgq9sjPjF /pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFEPV9allspkmYqkQRx2BlAdbOrjhMA4GA1UdDwEB /wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMF AjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggr BgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBPoE2g S4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wHgYDVR0RBBcwFYETZGlyZWN0b3JAb3BlbmNhLm9yZzANBgkqhkiG9w0BAQsFAAOCAQEA g+REupW946f7esdYmE1QxsYlkubErxz8JLovVDSKTHwxR1/VxF/B7rGeiSPBHTmKQYwlWCrp eHZNfzaDDkDamwLXm7v4+brNfQKRpOLnYPQQffp7xim72INakLgts8d5I7bic785dj4M5JP4 XA2qUD9wduwNwquua6v7zM3chpoRjapumzLNDDr47GccOKAZYaaqFwbpwJPQYuiC07WWnn7g FzdNKYN6VM6Re6wVEHP6fEvNrleV0pf1iFjLKugnriGKL9wj6xX25JsMmGmqZcfdpnkTE4Zf eQBEZVnn8s7HBX+MA/K+YnHxRwA2c5XwNbEhZ2rvh2uFIMXBDlt+tDCCBeYwggPOoAMCAQIC EGqb4Tg7/ytrnwHV2binUlYwDQYJKoZIhvcNAQEMBQAwgYUxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMSswKQYDVQQDEyJDT01PRE8gUlNBIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MB4XDTEzMDExMDAwMDAwMFoXDTI4MDEwOTIzNTk1OVowgZcxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNV BAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAvrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEup/Y0dtmEatrQ PTRI5Or1u6zf+bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypVpVSRsivl JTRENf+RKwrB6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYKjrc5NOpG 9qrxpZxyb4o4yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRikw8lBoNoS WY66nJN/VCJv5ym6Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsUtQIDAQAB o4IBPDCCATgwHwYDVR0jBBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0OBBYEFIKv bIz4xf6WYXzoHz0rcUhexIvAMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEA MBEGA1UdIAQKMAgwBgYEVR0gADBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9k b2NhLmNvbS9DT01PRE9SU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggrBgEFBQcB AQRlMGMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQUFk ZFRydXN0Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wDQYJ KoZIhvcNAQEMBQADggIBAHhcsoEoNE887l9Wzp+XVuyPomsX9vP2SQgG1NgvNc3fQP7TcePo 7EIMERoh42awGGsma65u/ITse2hKZHzT0CBxhuhb6txM1n/y78e/4ZOs0j8CGpfb+SJA3GaB Q+394k+z3ZByWPQedXLL1OdK8aRINTsjk/H5Ns77zwbjOKkDamxlpZ4TKSDMKVmU/PUWNMKS TvtlenlxBhh7ETrN543j/Q6qqgCWgWuMAXijnRglp9fyadqGOncjZjaaSOGTTFB+E2pvOUtY +hPebuPtTbq7vODqzCM6ryEhNhzf+enm0zlpXK7q332nXttNtjv7VFNYG+I31gnMrwfHM5td hYF/8v5UY5g2xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI06vzgkejL580ul+9hz9D0S0U4 jkhJiA7EuTecP/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8ydehzuZutLbZdRJ5PDEJ M/1tyZR2niOYihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2HsOgkL3VYnwtx7cJU mpvVdZ4ognzgXtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQzVxZx5/bRaTK TlL8YXLI8nAbR9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIEODCCBDQCAQEw ga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01P RE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAu2YC W4tRQdGHMc0S/FQsNDANBglghkgBZQMEAgEFAKCCAlswGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgxMDA0MTUyMjU1WjAvBgkqhkiG9w0BCQQxIgQghU2c UzkJiBxwTee/i5A8vJvzPTGyzdpQc1VHRwixzR4wbAYJKoZIhvcNAQkPMV8wXTALBglghkgB ZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBvgYJKwYBBAGCNxAEMYGwMIGtMIGX MQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdT YWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJT QSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRALtmAluLUUHR hzHNEvxULDQwgcAGCyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UE CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRALtmAluLUUHRhzHNEvxULDQwDQYJKoZIhvcNAQEB BQAEggEAlKic9IrGsyuF/UzBBWDGAXEHqTmNAsWeJqhWfGr3oWclCqnhGZm1QC3BncL9ye2p 9gSLgQJ8DBfIA4b7hJeqDQJNN2cJqoFF20QCdYuJ9CAvC37JXcEdcXf39eLIgzRWGxTQEslh uE36NsoQlaNkmYIAGfZ2RhrMqs5GyMBIALNAlEbYvdA+23JZDuNadRamcfWI0l4vGuAk8PKk lY95WFisV/BtI6yE7f8NsxPIRgC3nrG5L/bPHp2mHoEL3epFfg6Hv+ku3MWqkHLFmXEsSRWh vGFQKPvO9DWK85R23aeGgNNxbNjuCyOISoN0CxEqeWAVJxmCQ/xG/p6hn7usqAAAAAAAAA== --------------ms070001060004000500000706-- From nobody Thu Oct 4 09:57:25 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1F76130DD3 for ; Thu, 4 Oct 2018 09:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=comodoca.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBIR_i_XuIMJ for ; Thu, 4 Oct 2018 09:57:19 -0700 (PDT) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680043.outbound.protection.outlook.com [40.107.68.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C43E1130E5E for ; Thu, 4 Oct 2018 09:57:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comodoca.onmicrosoft.com; s=selector1-comodoca-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mT5UuXVNokg9ZcZMam8DK2BiINQax0fF7ptYbsWlE/A=; b=vtH/eMjJJPDCczqIi5qGW7LSVGQPCOER8VClVewmdMMfRlc6WS+iyVMgwNyApdsMv/2DcdZJZKqla1ieUd5K0vSP0xZxTDNSFDNHTLcgytNUCS9ZkjLC7fT6Wu8gcUlbQCjXzxGzHiSJ/O+NPiFHVV2Qaq6P5NIEIF0bhDQ9Y1Y= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=rob@comodoca.com; Received: from [192.168.1.81] (51.6.167.73) by BLUPR17MB0481.namprd17.prod.outlook.com (2a01:111:e400:c46b::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1185.25; Thu, 4 Oct 2018 16:57:15 +0000 To: "Dr. Pala" References: <90b6138b-acf9-0836-79e8-556c81d1029a@openca.org> From: Rob Stradling Cc: TLS WG Message-ID: <4f35e991-9aa7-48d3-bf83-ead7412d3ebc@ComodoCA.com> Date: Thu, 4 Oct 2018 17:57:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <90b6138b-acf9-0836-79e8-556c81d1029a@openca.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [51.6.167.73] X-ClientProxiedBy: LO2P265CA0123.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9f::15) To BLUPR17MB0481.namprd17.prod.outlook.com (2a01:111:e400:c46b::14) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6e666753-bba8-455f-7a5e-08d62a1a700c X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:BLUPR17MB0481; X-Microsoft-Exchange-Diagnostics: 1; BLUPR17MB0481; 3:YX0PSwAemrCrxMw2v456FIvRK7y1qejmXa8E5cBQD3Xu6d9ZeHxHQfAf69SrufVYvFCKAUfM+y21nTVjH8lOYsYrKBJbhII7xNpUKx7I8o9ckhwR6jqhNcvUbCd0whxf2MtYTYrtu2YXJnLCbbybBhJPyKB0TuVeLTu5R9Pe9SALPScGRBr34rBx7xdwpR8ljgdTf+uxVmCe8vp0UxypuH0jzYjpi8E85n5y9H2Z4e2LxFe+2MTGpBuas0/0GPDn; 25:8iVz1CIZ2iChNOOP2edYlpbVdVXZ85J9E23zWhEC1lQWK5VBnTOmITJLYJAQz6idu3o+KC/rZCKzJPhL+1Rj9utlXiz9d8nbFk+yccwR5qwIbYEWsuQ7GKOOve61MfXqUHX2Kd07IYjc4F+X75iApcpTsD9RabCaMyOn1mwaRGKoFMdqoetogCr2bnH90rDR9Emvzp6jeris1dykWTa17VARAQEkoKQ6XKl9/a2fRke4dcsOMHK4S0UrLjjOqvNiqZ4wOLJygIcahvi1BVNPpwe5fEkHDFNL9yHpoR+aMQXZ9jraFfOkoXyaZ6Af9fEQK5xcrIiCKjo3y0CAXNdVVA==; 31:ZCzTF1/d+Uwp0evsqoR0w4y4efuHvAaueftkq/JlnRa3fwz6lOwNaeYCPQYgeM4g+xAPB2NcjzwXQE1UvWENMeEU7wOJ13FbfnnovIZRoBvcTEMoWVAiEshvvwHsrjthRiNxzGqmxq3VS7wajF3z+vxpl9R4kLADS1L4P55kW4SO1ljzyXJuDyLulrvd7178IbYj6No8qvDc+MRad/V34H+aDtMzjCchwv9Z1jiBTP0= X-MS-TrafficTypeDiagnostic: BLUPR17MB0481: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(21532816269658)(158342451672863); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231355)(944501410)(52105095)(149066)(150057)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(201708071742011)(7699051); SRVR:BLUPR17MB0481; BCL:0; PCL:0; RULEID:; SRVR:BLUPR17MB0481; X-Microsoft-Exchange-Diagnostics: 1; BLUPR17MB0481; 4:XboSS9a9wkW9NprN2R1Nn9pRslb06yCdozK+tsRL5uAcoVEQsq8glVxwAXSUKjDqlkAxAo0rW3YOCh/cwnDS8YTxfeZReqzg2K2CC1k2m6NQjpxU317S1cAnZhoghw6mjIeH0ZBtlWRxwkWr7yqiDtoZXM2Dt/QRG1C4/vwMu2XXXg33JB599Q+eyyc6Wj1cf79IqxX74k3o6DCJV/eCDDM8kIRis2EhEzqrJVEKS6w6CklpwKckBZc1l6uUCg/IbF3tSSPangFWG6s4mGL0O2+YHcejJizHLECoSi8MYm7dLlndIj6QPr+3JNRYUGp7m8AaGwr1cNsJ4CaI4C+GJCWCf5rxqw4kBOWEq/ZJUio= X-Forefront-PRVS: 0815F8251E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(136003)(346002)(366004)(376002)(396003)(39850400004)(199004)(252514010)(189003)(53754006)(81156014)(16576012)(53546011)(50466002)(36756003)(2906002)(229853002)(23676004)(966005)(2486003)(68736007)(8676002)(77096007)(81166006)(230700001)(386003)(6486002)(52146003)(76176011)(6666003)(26005)(8936002)(15650500001)(65826007)(5660300001)(67846002)(64126003)(478600001)(11346002)(486006)(16526019)(31686004)(4326008)(97736004)(66066001)(31696002)(65806001)(65956001)(305945005)(316002)(186003)(86362001)(53936002)(106356001)(446003)(2616005)(7736002)(47776003)(6306002)(25786009)(6246003)(52116002)(117156002)(6916009)(105586002)(956004)(476003)(14444005)(6116002)(58126008)(3846002)(12269545002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR17MB0481; H:[192.168.1.81]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; Received-SPF: None (protection.outlook.com: comodoca.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTFVQUjE3TUIwNDgxOzIzOkhBa2E4WEM5YWo5UWVmK2MrQ1Q3VU9jV3lv?= =?utf-8?B?d3I2d1F2aTJOWmVCY1F3TU1Ub0JsQWUrbno5ODFFejFFS1BNZXBIUlNuWmww?= =?utf-8?B?RzFuSVNKNFlxbW16d0VrTFkwMkVOU3ZUS0RPeW5UcmJodWd0em93WTMxK2VF?= =?utf-8?B?aE5MYnY3dm9EMHp0cmJZeFpCRFJTZmROZ3FzK2ZsRU5pWEZIUkt4VlJ4bW9D?= =?utf-8?B?bGZuUHduNmdmdkQ4MkFXYzRpQWNOQ2hpMmJMai9tcktINEpiSVhoUEN6QVNM?= =?utf-8?B?TW5kRzNhcEdzMGRiMHZaMFlMbm5GS0NiT0MvTGFuY1pQaC9DMnNBYWpBUjdT?= =?utf-8?B?a05DZkdiczdtVC9TK1A0WS9zZjFJbzVzRmhndnZhT3Y2T1lSZUF2Ym9qVHlT?= =?utf-8?B?cVdEZmp3WW1Rd3VEUkR0OXVITHQ1dUVQaDVuTklLK2RwTjB0M0NaUll1Sm5h?= =?utf-8?B?RThYMGlXQW13a2dOREZhVlcxQnZuUlQ3UThaaElwWUppdGsxYzJvYW05dXRK?= =?utf-8?B?OTlUL25Jc2ptVGRRVkl6M2JKTk03bmZtMEk1NWpGQ05qSW1Da2hLMWM4QW1E?= =?utf-8?B?MGZaQm1lSGNpTVR2aTUxdlVUVFdHUGlaRlc5czhZMXFhYVpnckhmL2taeFRw?= =?utf-8?B?TGlVMWE4U2cwSUdkTlBaVjlCMURYMzNnZzRUUWNENnE3TGpXZTJlSFY4UHFI?= =?utf-8?B?TzVrVFQ1TUsycGZ0MUZEME1ZajBXZUhQT2pEV0l3Wk1rMW9jNXpYeG82MDYx?= =?utf-8?B?bk5DTzRwMVI2OENmM3paVE9OQnZsQ3ZLWE5xOXE1V0FQZHRtdXVyM0d0b1lz?= =?utf-8?B?ZDFRTUxOUlJFVE0xalR0T0pZNmoxeVpzcnhyRFhaejl5YUcxUWtNSXhURjVx?= =?utf-8?B?ZFV0czl0Nm1nSEFHVFVRM2IyV0tyWVBLd3R4Si9IVGp4UW5ZNVVoNndnUFJF?= =?utf-8?B?SXdoZHF2VnA2MHJwdTJZak1pUUJFQVcwcmhMRVFDaWd5K0t6L3lKTGZiR0dk?= =?utf-8?B?ZW5YcHl2OTllYmhOWUpPaWVveXYzYjRnM1VwVG5ocXJrRVBkTWxPZkowVWJi?= =?utf-8?B?bW5ndk1xeWhUSnRJSklxanU1MUE5bzFWLzVlVWc1TFBFenlDSkhib3VjMFRH?= =?utf-8?B?UktndUY0K0J5MSsvamYwNzJwSkJMWGhyaEppUXhaODBKY2xPbEQrcGNuYTVo?= =?utf-8?B?bjRGeUlrVTZ3SkVDVFp4dWhrbCtlWFRZNXkrL2tRNW9CamY5RVNCc3dPOVJ5?= =?utf-8?B?OVNYR1lyekpYSkJuVC90Vk9iNTU4YUxVZmJ2UzVjTUVOZjJYeUVEM0RPdWFp?= =?utf-8?B?K0RBWmRPbDBobXZWYnkvU2FTeWtVdEtHU3gvbDU5QUFOTGpVUE02Q0k0R1Zz?= =?utf-8?B?VXhHblgybnhxNFBlRExQUWFYNmQrdklISHJ6NmxhWS9CdGFXRVZjcUJaNnNh?= =?utf-8?B?emsrbDVMcEVSanJCTUU1eFE2bWJGRURyeURKWkUrRlpUcHl5eUNvYXNCNEQ3?= =?utf-8?B?N2E3eE5VM0k5T3Erc3pVeDFyaTgxZGhSOEF4TmFtWUhlSXlKT3RKbVZ0SVMx?= =?utf-8?B?NjhPcFhubUhpQ0xkdWhwb3FRSWdkQ3V3bXVXNngrWEZFOFVkQ3VOOGp1cTcv?= =?utf-8?B?U012a2gxK3hPSllsTWFZS3NOMVFMUm5rUEVESUpUazhhVERGRDZkMjNVc09M?= =?utf-8?B?dlJOcTFjdUtiYWY5eHVwRGhkbjc2aXl6ZjQ0cXllUzBJRG5HZGpBUWhxT2hq?= =?utf-8?B?SmpRWjkyVkdPeEZYKzY3TitsdHc5bnhjWUE1blRXS2F1UTlzb0hWSmZQRms0?= =?utf-8?B?T0ZzU29HRXhrSmN5SWIva0g1NWppTTF4VmZaYlVQN1QzVHhGdW1zY3ZDVmxW?= =?utf-8?B?WE1CUW5VTmNnSUYyMk44a3dMMkQwenF6RTBkbUhQZTVyZmgvTEpoV2FGeUN0?= =?utf-8?B?dnRERlhOL0FucWtpR2xlV096OUdzZ1ZKVk0xbG1zVFcyMXY3WTM1WTZPYVk5?= =?utf-8?B?RnREY01xSm1pQ1JRMSs1NnNQRzYzZFZEVVhnYlhCbE8yNHlZeUZhUzNmT09E?= =?utf-8?B?dlVwcWlWVndJdDhzclFBZzZBN08veVdjNDlLcGY4RkxscVpIZHFFS2QxOE1z?= =?utf-8?Q?5qE8MR3iV/zPu8pAphAmOhpDlZIvV0kwRB0BtQ+b6PSk?= X-Microsoft-Antispam-Message-Info: LwWnIboMdMPtuBLuBLpc9253EPEAh43l+ZCb5ToZ3QDwWHTTMHmZbxxIO8UBl4IJxGJqVbM0L9qTK2xT8p3sEx8AtdRa0kKXUwYZ6s19k1Ot+TXM5PElGiKXluXVr2UlRMbT/Q2d6USdAzsYrrAqwBysluyTnv75kO1lbZRzL9CkKYJoAXlz1vvyeUomHbQtr2pzwFN2DDYNIQDMS7QLZ0OqwuUuVkiUAxnn7KdBdLHsPjMSsF6d7/VhFuQ7Y6EKK1cHBHaT8GeXD4+MfxsFDRGvmZrC4f+VIUHruuoACumVIO01KHc4aglU3P0rbYeAM78mCv+K9ZnyPMe4bog98g9Vlayv4eFYJo3HQbjmO8A= X-Microsoft-Exchange-Diagnostics: 1; BLUPR17MB0481; 6:7bVyfjz30Be8G13AE/fKcP8SBCrfm99aizpnNtHQkSbRgcGHkckCcnKl6XcSAOZarzLJZ9ST8RIehzKfy2pZ1Xux4QmWnLdAP9pl3zcDxwnI8jqP/YHN2VCXXMv5GE33mZr2ATtE+NAoReG7sSSqtO99896TgeRnuEAlweqRBD/0s9V3cizqj+qanZBNledb9gusQ+CN1VKmFFTP5Puzjm/BbjBU2flMFQklADIK1FTvEHw4c0xhVPqRoVJFRluepUeLrD0uWg0YKIyB62M3LKSngydopR8aXULVPb4jDSlGgZrcymdi4dpEip88HknLUkWERrhor+7KewbiSgJGqxjYK8AVe/zAgR36053hgu0ENnsD98KcsNfTAmlIr3dz8DmPIV7bXQJO3nNVPn0Aa9WHEZvRLimPFY5xAxUsEyz2m48rtS55xyF2ZXuuS784u68f/WoPgdDguSdJC1rYkA==; 5:hk+uaJoBS+afsKtRU3bAfCN4gkkDEXaEN3EFuheXb1eTP2NUMJgt3LJ6/tCnLJKSHruri65PdhC9GVqGNV2pGczRIm6mV6ZkmfBSP/aiV3WrUSmu0Vv4ALbKbq2li8gfd/DHYZ94gKGNIBGJ0ULb0DmoJ8Dz+DKeNKy4PYiB43g=; 7:v2z2KC1jYdu0pag/ds1LGzHyc4YKaFzS+TJipVgvCV4OoKl/kvQKq6VgpSg7VGRUDejv0LCMzA947jfG7Gm/P7aHc8OR7Co0Y6VR1u+sxGlRnDYL2nV1TqtOV5OP6WvT1c5vOlmzgcyhgTEznvgzSXXzk9kresvaIdBM4OBgGiw51v/YFj57KjdbHoqsZ4Rx/C06sGEP+XA5YRBkEVGocUQlV6sEwAOIG3w/DhZzMCgpEUxppuj8p581SnaC21nl SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: comodoca.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Oct 2018 16:57:15.3135 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6e666753-bba8-455f-7a5e-08d62a1a700c X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 0e9c4894-6caa-465d-9660-4b6968b49fb7 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR17MB0481 Archived-At: Subject: Re: [TLS] How to Validate Servers' Identities w/out reliable source of time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 16:57:23 -0000 Hi Max. The most promising solution I've seen to this problem is Google's Roughtime protocol. Adam Langley's blog post: https://www.imperialviolet.org/2016/09/19/roughtime.html Protocol description: https://roughtime.googlesource.com/roughtime/+/HEAD/PROTOCOL.md Open-source implementation: https://roughtime.googlesource.com/roughtime Cloudflare's Roughtime service: https://blog.cloudflare.com/roughtime/ On 04/10/18 16:22, Dr. Pala wrote: > Hi all, > > I am struggling with one issue that we have been seeing more and more > often with the introduction of small IoT devices that connect to clouds > via TLS and need to validate the cloud server's (or the other party's) > certificate chain. > > In particular, the problem is that without a reliable (or trusted) > source of Time information, devices can not reliably validate > certificates (i.e., is the certificate even valid... ? is it expired ? > is the revocation info fresh enough ?) and my question for the list is > about best practices in the space. The problem is even more problematic > for devices with limited access to the network (e.g., access only to > specific servers / cloud services) since no "external" source of time > can be used. > > Do you know if there are indications / best practices from ITU or from > IETF (or other organizations) on how to deal with this issue ? Has the > issue been addressed somewhere ? > > Cheers, > Max > > -- > Best Regards, > Massimiliano Pala, Ph.D. > OpenCA Labs Director > OpenCA Logo -- Rob Stradling Senior Research & Development Scientist Email: Rob@ComodoCA.com From nobody Thu Oct 4 10:01:37 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA646130E78 for ; Thu, 4 Oct 2018 10:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ghedini.me Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHGsQcp1kFtN for ; Thu, 4 Oct 2018 10:01:33 -0700 (PDT) Received: from blastoise.ghedini.me (blastoise.ghedini.me [IPv6:2001:19f0:6c01:a56:5400:1ff:fe4a:5694]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37AAA130DD3 for ; Thu, 4 Oct 2018 10:01:33 -0700 (PDT) Received: from localhost (185-33-211-9.g3ns.net [185.33.211.9]) by blastoise.ghedini.me (Postfix) with ESMTPSA id 6393EDF68F; Thu, 4 Oct 2018 17:01:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ghedini.me; s=mail; t=1538672491; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=kTqpLoKCxZxIA2VUOQeC4WstzPOvVtmVdPzLoO+G+UY=; b=e8K1IzxyKp+mztg9jmyzFypE9thBApOYeNAGqzeZHJmHtP1jpbkLF9GUaqrD7a40Cygcvp wAIpFiGCAhXIFLLeja7/LX12XC3MwJcSEwVfTAK7sKzylAfNPUcgYkoPQZcuMzhSjjroKy ICIniyctN4hCV+U7UeEX5jAp/7aAhGI= Date: Thu, 4 Oct 2018 18:01:24 +0100 From: Alessandro Ghedini To: Sean Turner Cc: tls@ietf.org Message-ID: <20181004170124.GA13528@mandy.flat11.house> References: <153856977342.9010.10521757586695280@ietfa.amsl.com> <20181003123643.GA5454@mandy.flat11.house> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2018 17:01:36 -0000 On Wed, Oct 03, 2018 at 01:15:22PM -0400, Sean Turner wrote: > > > > On Oct 3, 2018, at 08:36, Alessandro Ghedini wrote: > > > > On Wed, Oct 03, 2018 at 05:29:33AM -0700, internet-drafts@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 Certificate Compression > >> Authors : Alessandro Ghedini > >> Victor Vasiliev > >> Filename : draft-ietf-tls-certificate-compression-04.txt > >> Pages : 7 > >> Date : 2018-10-03 > >> > >> Abstract: > >> In TLS handshakes, certificate chains often take up the majority of > >> the bytes transmitted. > >> > >> This document describes how certificate chains can be compressed to > >> reduce the amount of data transmitted and avoid some round trips. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/ > >> > >> There are also htmlized versions available at: > >> https://tools.ietf.org/html/draft-ietf-tls-certificate-compression-04 > >> https://datatracker.ietf.org/doc/html/draft-ietf-tls-certificate-compression-04 > >> > >> A diff from the previous version is available at: > >> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-certificate-compression-04 > > > > This is just a tiny update with a few small fixes and the addition of the > > early code points assigned by IANA. > > > > In other news, Chrome landed support for certificate compression in canary > > back in July, and Cloudflare deployed support on its edge servers a few > > weeks ago. > > > > The data we've seen on the Cloudflare side looks quite promising so far, > > although I haven't had the time to do a full analysis yet. We are seeing > > reductions in certificates sizes between 1.5-2 KB for both ECDSA and RSA > > (meaning a full QUIC packet if not more), with average compressed size > > hovering around 2.1-2.4 KB for ECDSA and 2.5-3.5 KB for RSA. > > > > The only remaining open issue is the potential attack illustrated by Subodh > > a few months ago https://www.ietf.org/mail-archive/web/tls/current/msg25851.html > > > >> From the reaction on that mailing list discussion, and from talking to people > > at the last IETF, it seems to me that the attack doesn't appear to worry people > > much and that there isn't much interest in fixing it. Though I thought I'd > > mention it again to see if people have anything to add to it, and see if we > > can agree on whether we should do anything about it. > > > > Other than that it looks like the draft is in a pretty good shape at this point, > > so it'd be nice to have some additional review, and then see if it can proceed > > to the next step (which I think would be WGLC). > > Alessandro - thanks for this update. > > WG - I’d like to echo Alessandro request for reviews. If this outstanding WG item is not resolved before IETF103 we will discuss the outstanding issue there, and barring any other major issues we are planning to WGLC the draft after IETF103. > > One question: There was some discussion earlier about dictionaries. Are dictionaries being used in the current deployments? No, neither Chrome nor Cloudflare are using dictionaries. Something I forgot to mention in my previous email is that the numbers are for plain brotli compression, so without dictionary. Cheers From nobody Thu Oct 4 18:00:12 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62322130DBE for ; Thu, 4 Oct 2018 18:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p_Ht6WWdM3gJ for ; Thu, 4 Oct 2018 18:00:08 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89EDD130DC3 for ; Thu, 4 Oct 2018 18:00:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1538701207; x=1570237207; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=zONgmbBI/67wrJ9ev9EBsLQdHIXr694yWQDIKip0Iz8=; b=x5GCWnGftmcqtgrVWPbGCCUFG+cKarl2T6MHWSmo6O0RMDkT9oTNlmrA Gr4S0T1R6ukkXtUJZd7ziypwj+QQPmMS4GxK0KyKt5MfQQ+96+Ecnd74J WXpxczQ92wuZR7bcJqjQoaqo/G/odYA3EW0IvD44BNkYHCSA0PamVBG/Y +0+Ko94t135YZ/9eoRXGr4BshIYjsC+wddAp/ujj9sElzldiWR7Wi3Res AGoDNDMQwBwNH31bxNsMyrFCDVg2EhDLNLmRHKKpttj1d4qHJtKEiR1fx xqc0THU/o6Xyrxvv48FpUeS4mf5JRWx53zok96rhRXiXwhY9Ag0eMjFBV Q==; X-IronPort-AV: E=Sophos;i="5.54,342,1534766400"; d="scan'208";a="33670698" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.8 - Outgoing - Outgoing Received: from uxcn13-ogg-e.uoa.auckland.ac.nz ([10.6.2.8]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 05 Oct 2018 14:00:04 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-e.UoA.auckland.ac.nz (10.6.2.8) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 5 Oct 2018 14:00:04 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Fri, 5 Oct 2018 14:00:04 +1300 From: Peter Gutmann To: "Dr. Pala" , TLS WG Thread-Topic: [TLS] How to Validate Servers' Identities w/out reliable source of time Thread-Index: AQHUW/Y9jpkjrxv0XkOq614twMG5P6UP1U2R Date: Fri, 5 Oct 2018 01:00:04 +0000 Message-ID: <1538701198755.6342@cs.auckland.ac.nz> References: <90b6138b-acf9-0836-79e8-556c81d1029a@openca.org> In-Reply-To: <90b6138b-acf9-0836-79e8-556c81d1029a@openca.org> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] How to Validate Servers' Identities w/out reliable source of time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2018 01:00:11 -0000 Dr. Pala writes:=0A= =0A= >In particular, the problem is that without a reliable (or trusted) source = of=0A= >Time information, devices can not reliably validate certificates (i.e., is= =0A= >the certificate even valid... ? is it expired ? is the revocation info fre= sh=0A= >enough ?) and my question for the list is about best practices in the spac= e.=0A= =0A= It depends what your goal is.=A0 Are you doing the validity checking becaus= e=0A= some document says you need to, or because it's required for an actual=0A= security goal?=A0 You mention IoT, in a lot of embedded/SCADA there's littl= e to=0A= no checking done because the goal is as close to 100% uptime as achievable,= =0A= and shutting down because of an expired cert when everything else is operat= ing=0A= normally is a absolute no-no.=0A= =0A= What security and non-security goals are you aiming for?=0A= =0A= Peter.=0A= From nobody Mon Oct 8 17:09:56 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1779130FCE for ; Mon, 8 Oct 2018 17:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1_G4xZi_LYSy for ; Mon, 8 Oct 2018 17:09:53 -0700 (PDT) Received: from mail-it1-x135.google.com (mail-it1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 509F0130FA2 for ; Mon, 8 Oct 2018 17:09:53 -0700 (PDT) Received: by mail-it1-x135.google.com with SMTP id w200-v6so139157itc.4 for ; Mon, 08 Oct 2018 17:09:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Jgx9Ow148ZLbBZbCW5uX8zV0t+3jQdE+BZsVDRLYuDU=; b=vL5tsvbKLpVqasPeezIfiYqBbrfgRs/hzHxdhTjJJ3ru1djMWMXGYYwhaUVjOv6jS0 EWE2ZRnAvRyDQ+a4aLe03AZlJ9E9IY7eEsQlLUYGLiGTGisBFOoC/4mS2TC4ULpE0l/h 6fASAzvc10yiztMk5E/LTUoFylrIMPDlEj5z/U2KfQ0UwdQlwNG0opdI+FvzZImsmkvF 2Mafp6poU8d9YPi+nBzUuYvPepR4BWaaEIV1DDi8K36Qg8kCeKGHhu8xKNsx/CVI0+b3 9QddRKNt+lRnACCOlhgcAq7f8CYoMKkkfvFxrbOR0MxxTbDneF+zW+hIPT12TBeT0OXc hrVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Jgx9Ow148ZLbBZbCW5uX8zV0t+3jQdE+BZsVDRLYuDU=; b=QyD23dTYpflafq7RXeKZPELPcWXkf+Z3gI+G5puAXMou2Ay7o3eiNXulTNa/PScrRg Yd0LNvw3oOgy8dr2wvylXeBTTMPBclSdd0s3unMj6lUDEhznKrsb87fYimxylkMXmGDv Mcba/60vInmpQNhalRgKvMZf1NXBDJcmlmUergH9ZyLIANPSmMjizdsZqRFjzbcZK//w 5o7wgb0Y+ttfL9tCjwhlUJzSVoa6KXc7eJzK0DpH0QMOnIJuBG5c4ZeK7pgt9F+jeRJV 9Z6YU2pOsB3wakbLL9ms8el/Sw4By1EBl+BSZnsrg5joxm4VKEu/txZLPhA+e+jDnzel mZ2g== X-Gm-Message-State: ABuFfojQAZbU5ykOAnzEYBELWL6WUd5lB5xxacGeBM1HTPtfJqgwNCoz iexZ4nPvc5oIPmhyQEhrHmPaAqd7pNS1qX4DjDRJrVjU X-Google-Smtp-Source: ACcGV62DrgQaQSGerM9aR92r4B0gZSXpHTkWrlQky8t6MbqhqH++qo1GRelsAVLKla82XfJLVjvQZgZPHRJLxPs6lNk= X-Received: by 2002:a24:4ac5:: with SMTP id k188-v6mr171080itb.158.1539043792113; Mon, 08 Oct 2018 17:09:52 -0700 (PDT) MIME-Version: 1.0 From: Christopher Wood Date: Mon, 8 Oct 2018 17:09:40 -0700 Message-ID: To: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 00:09:55 -0000 Notes from the TLS interim meeting held in September are now online [1]. To recap, the meeting attempted to focus on three primary questions: 1. What is the fundamental security issue? What is the purpose of this extension? 2. Under what circumstances should DNS records received in the extension be cached and reused for future use? 3. Is pinning required? If so, what is pinned, and at what layer(s) should it be implemented? Most of the time was spent on question #1. In an attempt to get to the root cause of the disagreement amongst participants, we have since attempted to go back to a clean slate, gaining an understanding of the "facts on the ground" that motivate a need for this extension and how current technologies operate, and move forward from that common understanding to reach a shared picture of a clear problem statement. Once a clear problem statement is agreed upon, it should be easier to analyze proposed solution(s) for whether they solve that problem statement without introducing unacceptable risks into the broader ecosystem. To that end, here are some facts for which there seems to be consensus: 1. DANE provides two major use models. In the first model, it requires that the server supply a certificate which would pass WebPKI validation but must also have a CA certificate (usage 0) or EE certificate (usage 1) which matches the TLSA record. In the second model, the server may have a certificate or raw public key which need not pass WebPKI validation, but either must chain to a certificate which matches the TLSA record (usage 2) or must itself match the TLSA record (usage 3). In the former model, the server operator still must participate in the Web PKI, whereas in the latter model, it need not do so. 2. Currently, DNSSEC failures are common in the last mile. Residential routers and ISPs, might give out DNS resolvers that fail to deliver (accurate) DNSSEC records. This makes delivery of DNSSEC (and TLSA) records difficult. Thus, any client which must work in any network environment cannot safely fail on DNSSEC failures (whether that failure is overridable by the user or not) because that would result in an unacceptable rate of failures. Further, clients have been reluctant to implement even opportunistic use of DANE records because of errors and latency concerns. 3. Certificate switching based on ClientHello contents is standard practice, e.g., as is done for SNI-based certificate selection or for servers which support multiple algorithms such as RSA and ECDSA. This may also be used to monitor the deployment rate of this extension. At risk of discussing a solution to the wrong (or a different) problem, we should first settle the question about the purpose of this draft. Once we settle on the problem(s) and determine if the proposal adequately addresses it, we can then discuss technical details. In the interest of moving things forward before Bangkok, we plan to timebox these discussions as follows: - October 8 through October 19: Discuss the problem statement. In particular, if anyone feels the problem statement captured in the draft introduction [2,3] or in the above "facts" is incorrect, imprecise, or misleading, please say so, and say why (in a succinct fashion). Questions regarding client pinning of the TLS extension, the risks involved in doing so, and how server operators can recover from pin DoS attacks are out of scope for this discussion. - October 22 through November 2: Discuss the draft [2,3]. The chairs will circulate a list of concrete questions to address before the 22nd. - Bangkok: Discuss the draft [2,3] and open issues. - After Bangkok: Call for consensus to continue iterating on the draft as a WG item or abandon it, and proceed accordingly. Best, Chris, Joe, and Sean [1] https://datatracker.ietf.org/doc/minutes-interim-2018-tls-01-201809141000/ [2] https://tools.ietf.org/html/draft-ietf-tls-dnssec-chain-extension-07 [3] https://github.com/vdukhovni/dnssec-chain-extension/tree/for-interim From nobody Tue Oct 9 08:54:05 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1CF13135A for ; Tue, 9 Oct 2018 08:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ritter.vg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWgXKbSht4mS for ; Tue, 9 Oct 2018 08:54:01 -0700 (PDT) Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87B5913134F for ; Tue, 9 Oct 2018 08:54:01 -0700 (PDT) Received: by mail-it1-x12f.google.com with SMTP id q70-v6so3382001itb.3 for ; Tue, 09 Oct 2018 08:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=S/ek9lHsPxkZ4N2+cQXktGPrcuc4cHBPl/iegO/08bY=; b=ZXV5O3jGy758/18tuBK06661dBSAk3LVVg7I15pKSbHoMBtLYDZutu/jC2jDpjMMP6 XwS2KAtsBgtS+8G9r0belicpCZBzo/SuVzKHxtNjlEm0iPK1mi9xydI/dIRazHRXlZDx lFzpI+Exe6jHwx6ii9gN7Kx1VS2EFLgsWfGsk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=S/ek9lHsPxkZ4N2+cQXktGPrcuc4cHBPl/iegO/08bY=; b=GvodPM0MbxH+A5SdgBd691HAToEUTyp5hNTUSqc8L/NPZOY//SeaMIJ5A8NgTJDk0Q M0UmHS4f25/VP4G4lqPnF3H94f+JqqxPVbsxjUjJkEpTM9sFOe78DrqWwm03ACJYUAl1 d81Xtgf3Uof6xoLaTd3z9zAqBVpeQOyXjK+s6wxATcEG3H3xTg9S5Jos2vGnExwLXE6Q QUeH/kM+RQ59FHzTgGRlqWUPTOKL5aBKCvo7+DDfHwq1NxWPh8iel+j7cRqdYLLWRSNx mA0bph8ruA4wBUKt9L9YSq2G4VQ1DnIMVvszDmbdCELAVF6Es6H8SPFeTXdjc27Qm0iQ Lexw== X-Gm-Message-State: ABuFfog/nLtdvO3EgFgTYeN/p5AJvDOpKT1y0/+ugWqH5ZplQl+IvDBK t/2Lu2VMDu3iLNlAVHnsD21ZcyqqN/iLDP32MDwv/A== X-Google-Smtp-Source: ACcGV62yq6UhyAJevNB/lkDLuzhZAkl+ns31aTURsH/Y+Upay5nCyimgDPR2vdB3D/tf1tkm+RyqT1AA6xj2Tq+NneE= X-Received: by 2002:a24:da42:: with SMTP id z63-v6mr2132647itg.111.1539100440672; Tue, 09 Oct 2018 08:54:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tom Ritter Date: Tue, 9 Oct 2018 15:53:48 +0000 Message-ID: To: christopherwood07@gmail.com Cc: TLS WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 15:54:04 -0000 I was not at the interim, so this email comes without context of that discussion. Apologies if this was exactly what the chairs didn't want... On Tue, 9 Oct 2018 at 00:10, Christopher Wood wrote: > - October 8 through October 19: Discuss the problem statement. In > particular, if anyone feels the problem statement captured in the > draft introduction [2,3] or in the above "facts" is incorrect, > imprecise, or misleading, please say so, and say why (in a succinct > fashion). I agree with the facts presented in the email. I find the problem statement in Section 2 of https://tools.ietf.org/html/draft-ietf-tls-dnssec-chain-extension-07 to be imprecise. Whether or not something is imprecise is often only discoverable in hindsight, given disagreements about it. That seems to be the case here. Specifically, it does not state if the intent of the draft is to enable a *server* to limit authentication of itself to this mechanism. It only talks about enabling a client to authenticate the server. Basically the draft doesn't say if it's supposed to specify a pinning mechanism or not. Since it omits it, my assumption would be that it _would_ not and _should_ not specify a pinning mechanism. (If it did specify a pinning mechanism, then the draft is solving a problem not explained in the introduction.) -tom From nobody Tue Oct 9 12:18:43 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF3512F1A2 for ; Tue, 9 Oct 2018 12:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Gvidtz5Rrvo for ; Tue, 9 Oct 2018 12:18:40 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB5EC12D7F8 for ; Tue, 9 Oct 2018 12:18:39 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 4D066307228; Tue, 9 Oct 2018 15:18:38 -0400 (EDT) Date: Tue, 9 Oct 2018 15:18:38 -0400 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20181009191837.GC3594@straasha.imrryr.org> Reply-To: tls@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 19:18:42 -0000 > On Oct 8, 2018, at 8:09 PM, Christopher Wood wrote: > > 1. What is the fundamental security issue? What is the purpose of this > extension? > 2. Under what circumstances should DNS records received in the > extension be cached and reused for future use? > 3. Is pinning required? If so, what is pinned, and at what layer(s) > should it be implemented? 1. Some applications that would take advantage of DANE cannot do so because they can't use DNSSEC directly. Either because of last-mile problems or perhaps out of latency considerations (though often the lookups can be made in parallel). 2. The stated purpose of the draft, per its introduction, is to enable such applications to obtain the requisite DNSSEC records in-band from the TLS server, thereby avoid both problems in (1). As noted by Richard Barnes, this even also resolves potential UKS attacks in some protocols, that inherent in DANE without certificate name checks, as with raw public keys, or the advice of RFC7671 Section 5.1 https://tools.ietf.org/html/draft-ietf-tls-dnssec-chain-extension-07#section-2 This draft describes a new TLS [RFC5246] [TLS13] extension for transport of a DNS record set serialized with the DNSSEC signatures [RFC4034] needed to authenticate that record set. The intent of this proposal is to allow TLS clients to perform DANE Authentication [RFC6698] [RFC7671] of a TLS server without performing additional DNS record lookups and incurring the associated latency penalty. It also provides the ability to avoid potential problems with TLS clients being unable to look up DANE records because of an interfering or broken middlebox on the path between the client and a DNS server [HAMPERING]. And lastly, it allows a TLS client to validate the server's DANE (TLSA) records itself without needing access to a validating DNS resolver to which it has a secure connection. This mechanism is useful for TLS applications that need to address the problems described above, typically web browsers or SIP/VoIP [RFC3261] and XMPP [RFC7590]. [...] 3. The draft's intended scope is not and should not limited to *just* "green field" applications such as DPRIVE, where use of the extension might be always mandatory, or otherwise based on static local policy for designated peers. 4. Without static client policy, existing applications (e.g. web browsers), can't know a-prior which servers are expected to support the extension and which are not. 5. Absent such knowledge, they're vulnerable to stripping of the extension on first contact, by an attacker able to provide valid WebPKI credentials (unchanged status quo ante for majority of servers). 6. Let's Encrypt certificates are both cost and hassle free. For a an existing application service (not "green field") there's no substantive disincentive to having a WebPKI certificate that ensures interoperability with a majority clients that will at least initially, and perhaps indefinitely, support only WebPKI. 7. If the WebPKI were sufficiently secure to preclude any concerns about (5), then there'd be no need to bother with DANE. Nobody would ever use a BGP MiTM attack to demonstrate domain control (run a server on port 80, respond to an intercepted email to "admin@", forge unsigned DNS replies, ...). 8. If on the other hand, back in the real world, one has legitimate concerns about the security of DV certificate issuance (knowing that compromise of the DNS registrar account used to manage DNSSEC records also necessarily compromises ACME), then one might actually want one's DANE TLSA records to securely restrict the acceptable certificate chains to match the these records in a manner that is not trivially downgraded to the ability to obtain a WebPKI certificate. 9. Not only is the extension subject to stripping by an adversary that subverts DV certificate issuance, thereby eliminating all of its benefits when not enforced by client policy (a-priori static pinning), it still carries costs in the form of needing to keep any TLSA records correct or else risk failure when clients that support the extension see non-matching certificates. The above is discussed in Ben Kaduk's proposed additions to the security considerations back on Jun 1. a. There are other gaps in the document. i. Failure to explain that when the server caches DNS data for multiple responses, it must decrement TTLs when transmitting "aged" data to clients. ii. Failure to adequately explain interactions with virtual hosting iii. Failure to mandate SNI, or to convey the server port in the client extension to deal with DNAT. iv. Pointless ordering constraints on the DNS RRsets, that don't work well when CNAME and DNAME records are involved. So before we discuss remedies, I'd like to hear whether there's substantive disagreement with the above statement of the problem. A discussion of remedies if we don't yet agree on the problem at hand would likely lead to much miscommunication. -- Viktor. From nobody Wed Oct 10 09:43:35 2018 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC926130F82 for ; Wed, 10 Oct 2018 09:43:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.86.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153918981289.5783.12445032016747669759.idtracker@ietfa.amsl.com> Date: Wed, 10 Oct 2018 09:43:32 -0700 From: IETF Secretariat Archived-At: Subject: [TLS] Milestones changed for tls WG X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 16:43:33 -0000 Changed milestone "Move ECC-based CS to Standards Track", resolved as "Done". URL: https://datatracker.ietf.org/wg/tls/about/ From nobody Wed Oct 10 11:54:23 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F29D126F72 for ; Wed, 10 Oct 2018 11:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7d7iUUsSm-k for ; Wed, 10 Oct 2018 11:54:20 -0700 (PDT) Received: from pdx1-sub0-mail-a65.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3C8E124BE5 for ; Wed, 10 Oct 2018 11:54:19 -0700 (PDT) Received: from pdx1-sub0-mail-a65.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a65.g.dreamhost.com (Postfix) with ESMTP id 7FC6A7FB7D; Wed, 10 Oct 2018 11:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=nn+GQiF3sE9FcP /OdGiqQ02Og9g=; b=M1mOo/xDyTJIcPcrYcqAz3+FRnhGHnaoH8tfFgQKnLTCpz GxKIS25PNPnQQWmaLVBQF0DpEOFrgOy5bsHO5Uh+OPNJbTToIe/nncNYUkXp/QfQ WoDpSqueNoAiQCb+ZDoBw/h/OvkQwt6ulNaGV0bfflUUTHtm1PC4QF914x1a4= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a65.g.dreamhost.com (Postfix) with ESMTPSA id DF89F7FB6E; Wed, 10 Oct 2018 11:54:17 -0700 (PDT) Date: Wed, 10 Oct 2018 13:54:15 -0500 X-DH-BACKEND: pdx1-sub0-mail-a65 From: Nico Williams To: Christopher Wood Cc: "" Message-ID: <20181010185414.GA22913@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrudeigdduvdelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Archived-At: Subject: Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 18:54:22 -0000 On Mon, Oct 08, 2018 at 05:09:40PM -0700, Christopher Wood wrote: > Notes from the TLS interim meeting held in September are now online > [1]. To recap, the meeting attempted to focus on three primary > questions: > > 1. What is the fundamental security issue? What is the purpose of this > extension? Broad utility vs. narrow utility. As specified the extension is only of use to clients that can mandate it and hard-fail when it is not supported. We are asking for Motherhood and Apple Pie. Who could disagree?! And yet many do. There is a reason for that. >From the concall and off-list exchanges I believe that the disagreement with Motherhood and Apple Pie stems from a belief that we can't get them at an acceptable price. People have been traumatized by the HPKP experience and want nothing like it -- and *this* sure is something I believe we *all* agree on at this time. Therefore I propose that we put the cart before the horse. I propose that we start by showing that the proposed Motherhood and Apple Pie feature is indeed cheap and risk-free, and not HPKP redux. If we can examine that statement, that the proposal is cheap and risk-free, and if we can come to agreement on that, then agreement that we should aim for broad utility will surely follow. Otherwise, and if no one else has an alternative cheap-and-risk-free Motherhood and Apple Pie proposal, then we can safely reject broad utility. HPKP is a *footgun*. Any attempt to add new footguns like HPKP must be rejected. > 2. Under what circumstances should DNS records received in the > extension be cached and reused for future use? The payload contents are DNS responses. They may be cached, or not, as usual. The choice of transport does not affect this. > 3. Is pinning required? If so, what is pinned, and at what layer(s) > should it be implemented? If clients keep no state at all (about the DANE extension) between TLS handshakes, then the extension can be stripped off (or the client redirected to a server that won't provide it). This is the source of the observation about broad vs. narrow utility. Now, we cannot, indeed MUST NOT, pin anything that would make this like HPKP. Otherwise we'd have a footgun for sure! That means: - MUST NOT pin *any facts* about how the server is to be authenticated! Meaning: - MUST NOT pin public key material (private keys get lost, rotated) - MUST NOT pin EE certs (same reason) - MUST NOT pin TLSA RRset RDATAs (same reason) - MUST NOT pin intermediate certs (operator might need to switch CAs) - MUST NOT pin trust anchors (same answer) - MUST NOT pin TLSA RRset existence (zone might stop being signed) - MUST NOT pin whether the server's RRsets are signed (same) - MUST NOT pin any other authentication facts not listed above That's a pretty extreme list of must-not-pin items. ALSO: whatever state is kept -whatever is pinned-, the pin must be trivial for server operators to clear. There is only one thing that's left to could get pinned: whether the server supports the extension, with an expiration time on the pin. We need to demonstrate that pinning server support for the extension does not a footgun make. That's on us. The test for whether we have a footgun is: can the server operator clear the client pins trivially in the event of a screwup? If the server operator can clear the pins trivially, then we have no footgun. Well, we have 1 way to set the pin, and 3 ways to clear it. There must be methods for clearing the pin that are no more difficult to execute than setting the pin. To set the pin: - the client MUST have requested the extension - the server MUST respond with the extension - the server MUST have TLSA RRs and a valid DNSSEC chain - the client MUST have authenticated the server per-DANE using the attached chain - the server MUST have advertised a non-zero pin time To clear the pin: - method #1: Same as setting the pin, server advertises a zero pin time. - method #2: Unpublish TLSA RRs or unsign the zone, therefore the server MUST send an authenticated denial of existence (DoE) back to the client. The client then MUST clear the pin after authenticating the DoE regardless of whether it successfully authenticates the server. (Recall that the fact of a zone's not being signed can itself be proved in DNSSEC, thus, no longer signing the zone leads to authenticated denial of existence.) - method #3: Same as method #2, but the client can independently check DNS if the server somehow does not support the extension. This only works for clients that can reach the DNS, but that would be e.g., most browsers, most of the time. That is, this works for clients for which this extension functions as an optimization. Clients that cannot reach the DNS directly were likely ones like DPRIV that want to hard-fail on server non-support for the extension anyways. Because there is a method for clearing the pin involving only local configuration (#1) no different from setting the pin, and because there is a method for clearing the pin involving only DNS change control (#2 and #3), including one (#3) where the server need not even support the extension that it needed to set the pin in the first place... ...there is clearly no footgun: the server operator can clear the pin at will with less -and in no case more- effort than it took to get the pin set in the first place. Now, to be fair there was also discussion of a denial of service attack. In the DoS attack an attacker who thoroughly compromises the server can install the extension, set the pin, then uninstall the extension and watch the server operator suffer. This also applies to HPKP, and it never happened, but the HPKP footgun was fired, so the DoS threat in not realistic just based on experience. But also, the DoS requires such a thorough compromise of the server as to make the DoS concern the operator's least concern. But suppose the DoS threat weighs heavily on everyone's mind! Clearly, if server support for the extension is universal, then the DoS threat vanishes. Therefore we offer a mitigation for the DoS case: slow ramped client- side scaling of advertised pin times. That is, initially the maximum advertised pin time could be just hours, and it could stay that way for N years, then quickly ramp up to a maximum in the range of a few years. That is, we can make pinning something that comes into force only enough time into the future that anyone suffering from a DoS before then need only wait a short amount of time, and anyone suffering from a DoS after then need only enable a by-then-universally-supported extension. Surely client-side pin scaling based on time since the extension's publication as RFC is enough to dismiss the DoS concern entirely. Thus we have neither footgun nor DoS concerns. Yes, we can haz Motherhood and Apple Pie. Q.E.D. Nico -- From nobody Wed Oct 10 15:09:17 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2036B12958B for ; Wed, 10 Oct 2018 15:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oV-WrLomMajN for ; Wed, 10 Oct 2018 15:09:14 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CECE128CFD for ; Wed, 10 Oct 2018 15:09:14 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id o17-v6so7645516qtr.1 for ; Wed, 10 Oct 2018 15:09:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=NNCcqZV9X/mQLgGmZv4Pv5nvGFf28YbQV9WxAQG2Za4=; b=Df8g6hutKG9fXRfSoxCHe8uCNcB4aupJJIPHrZt6VsePDXfnYMSNn2gakxbt4lMGWX f4yD+Jjhg3EZOCIv7N09uScZZOWcStq0ctC0ubk3wDLc+w1uKkvEm3YveTUqikOpym7t G92EBCPZJz6pSXKivZP2O+teRCF88EqEK97fg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=NNCcqZV9X/mQLgGmZv4Pv5nvGFf28YbQV9WxAQG2Za4=; b=Z6rYI7025yReM8NovGxQwvLcIFMxGlzrxGwYmrGTGGclelnW1IsatWornT6pHs/DYo tA+7SOpWr+/Ze7YlO+X0D9gLd0m4L4TLZJA1WzJe+XCUseyDQFkuyuom/PUSyuJeGXQp w1IkdqhzE2RGXLHaGu4L9u4OkpiZG1RnjW5AgRs+kKOc8+RgRf63ppVA+oNL36ti6NGX xcVGRX/pBoF5vW35SZzohUDq6J0SXghZNbAHy/Zn6fpAla8dt580GeSP7Diw/wqi9D3i 4zRQUvni8XYcVvgXWVGNsWrFGuelq4dQN2j28medO5TavWsTnXRfBYOU9KhtU7Y+zLWn jFvA== X-Gm-Message-State: ABuFfohPKg/t6O+lhLditSaMjq+KrHrEHH7v0dPCQfuEKjiRCX2lqoDA pqrwUW/xF2QPLqc9PXtBnPKRUa8SgHU= X-Google-Smtp-Source: ACcGV62ZApHh+H72mgjcFwSoi3Os+VFCTVTDSiUnKHrqo34Qjep74ycW26+d56OBoY3dHX89+xlw4w== X-Received: by 2002:a0c:d032:: with SMTP id u47-v6mr29615950qvg.245.1539209353349; Wed, 10 Oct 2018 15:09:13 -0700 (PDT) Received: from [172.16.0.18] ([96.231.224.191]) by smtp.gmail.com with ESMTPSA id l43-v6sm15376291qtc.80.2018.10.10.15.09.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Oct 2018 15:09:11 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 10 Oct 2018 18:09:08 -0400 References: <731A3824-C45D-416B-AACD-B1AC4D8DEFD3@sn3rd.com> To: tls@ietf.org In-Reply-To: <731A3824-C45D-416B-AACD-B1AC4D8DEFD3@sn3rd.com> Message-Id: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [TLS] TLS@IETF103: Agenda Topics X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 22:09:16 -0000 This is a reminder to submit agenda topics for IETF 103. We currently = have two slots scheduled [0] so if you are requesting time please have a = look at the agenda and indicate which day works best. spt [0] https://datatracker.ietf.org/meeting/agenda/ > On Sep 20, 2018, at 08:31, Sean Turner wrote: >=20 > The TLS WG will be meeting @ IETF 103 in Bangkok. To help the chairs = get a better handle on how much time we will need for our session, = please send in your agenda requests to tls-chairs@ietf.org. Along with = your request please provide an estimate for how much time you will need. >=20 > Cheers, >=20 > CJS From nobody Thu Oct 11 06:19:47 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 791A2130E6B for ; Thu, 11 Oct 2018 06:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXDyP2e9eP8l for ; Thu, 11 Oct 2018 06:19:32 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98AE8130DE4 for ; Thu, 11 Oct 2018 06:19:32 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 0C996B8009D; Thu, 11 Oct 2018 06:19:14 -0700 (PDT) To: turners@ieca.com, tim.polk@nist.gov, kaduk@mit.edu, ekr@rtfm.com, christopherwood07@gmail.com, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: eugene.adell@gmail.com, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20181011131914.0C996B8009D@rfc-editor.org> Date: Thu, 11 Oct 2018 06:19:14 -0700 (PDT) Archived-At: Subject: [TLS] [Editorial Errata Reported] RFC6176 (5520) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 13:19:36 -0000 The following errata report has been submitted for RFC6176, "Prohibiting Secure Sockets Layer (SSL) Version 2.0". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5520 -------------------------------------- Type: Editorial Reported by: Eugene Adell Section: 2 Original Text ------------- o Sessions can be easily terminated. A man-in-the-middle can easily insert a TCP FIN to close the session, and the peer is unable to determine whether or not it was a legitimate end of the session. Corrected Text -------------- o Sessions can be easily terminated. A man-in-the-middle can easily insert a TCP FIN to close the session, and the peer is unable to determine whether or not it was a legitimate end of the session. o The root certificate authority keys are overexposed. The server sends only one certificate signed by a root certificate authority, which means a frequent use of this authority keys for signing new certificates. This use can lead to key loss and the compromise of all certificates previously signed including the root certificate. Notes ----- Adding a deficiency. Recent history showed that well-known authorities could loose their keys and it had a wide impact on security. SSL 2.0 limits the certificate handshake message to one single certificate, thus making it impossible to send a certificate chain. A certificate chain doesn't completely prevent key loss, but it gives more protection to the root certificate keys which can be stored and hidden until we need them again, which is much less often than without chaining. 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. -------------------------------------- RFC6176 (draft-ietf-tls-ssl2-must-not-04) -------------------------------------- Title : Prohibiting Secure Sockets Layer (SSL) Version 2.0 Publication Date : March 2011 Author(s) : S. Turner, T. Polk Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Thu Oct 11 06:27:10 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9AE1130DE4; Thu, 11 Oct 2018 06:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddV2qD3lzuqo; Thu, 11 Oct 2018 06:27:00 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E1D4130DD6; Thu, 11 Oct 2018 06:27:00 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id BC838B804DC; Thu, 11 Oct 2018 06:26:41 -0700 (PDT) To: eugene.adell@gmail.com, turners@ieca.com, tim.polk@nist.gov X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: ekr@rtfm.com, iesg@ietf.org, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20181011132641.BC838B804DC@rfc-editor.org> Date: Thu, 11 Oct 2018 06:26:41 -0700 (PDT) Archived-At: Subject: [TLS] [Errata Rejected] RFC6176 (5520) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 13:27:02 -0000 The following errata report has been rejected for RFC6176, "Prohibiting Secure Sockets Layer (SSL) Version 2.0". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5520 -------------------------------------- Status: Rejected Type: Editorial Reported by: Eugene Adell Date Reported: 2018-10-11 Rejected by: EKR (IESG) Section: 2 Original Text ------------- o Sessions can be easily terminated. A man-in-the-middle can easily insert a TCP FIN to close the session, and the peer is unable to determine whether or not it was a legitimate end of the session. Corrected Text -------------- o Sessions can be easily terminated. A man-in-the-middle can easily insert a TCP FIN to close the session, and the peer is unable to determine whether or not it was a legitimate end of the session. o The root certificate authority keys are overexposed. The server sends only one certificate signed by a root certificate authority, which means a frequent use of this authority keys for signing new certificates. This use can lead to key loss and the compromise of all certificates previously signed including the root certificate. Notes ----- Adding a deficiency. Recent history showed that well-known authorities could loose their keys and it had a wide impact on security. SSL 2.0 limits the certificate handshake message to one single certificate, thus making it impossible to send a certificate chain. A certificate chain doesn't completely prevent key loss, but it gives more protection to the root certificate keys which can be stored and hidden until we need them again, which is much less often than without chaining. --VERIFIER NOTES-- This isn't an error in the original document. It's new text you want to add. -------------------------------------- RFC6176 (draft-ietf-tls-ssl2-must-not-04) -------------------------------------- Title : Prohibiting Secure Sockets Layer (SSL) Version 2.0 Publication Date : March 2011 Author(s) : S. Turner, T. Polk Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Thu Oct 11 08:10:21 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC37130DD3; Thu, 11 Oct 2018 07:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gv9qqvjY3kh0; Thu, 11 Oct 2018 07:49:50 -0700 (PDT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 889F4126CC7; Thu, 11 Oct 2018 07:49:50 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id 143-v6so9239685wmf.1; Thu, 11 Oct 2018 07:49:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iz5IosGXpVeAwbSBwq1zV7m3t7HMb+xwp/rhELUbM+E=; b=n8BqNq+vkFGKKHjPmg3+85+IrhCn1Vu4Kolv6DD49BA1T8GkRVK/jMTDU588N5Y990 RUeAy7nHtcSha0E98tQ9PDc/ZBk6OBRqbX84UHDEN8r9WAYtb+vKT30zwn4COmtK1NaH NV/9qNDp/vSH8IPuQWYewzLYv7dPmLDyG0BJ61dZ7yeA4um4wTPo6UrJauH1xE1WvDnY /fCruXyStB6udHJkbZsuCgBBtgYWlsrnuYBOrmAtPN7Z3/Ce2zXQHGDRIsGen0e4oOtl JIXME14sGHi5JAmdI3RSDBxd4AnK3Zl4JV9dpNxZaXWxSMvJG7Bejsjy27A3kM67w3mI gxWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iz5IosGXpVeAwbSBwq1zV7m3t7HMb+xwp/rhELUbM+E=; b=H52EUnZ1rvKxsvW2YKuaVZ7SCasWPwYvuw5Q3p2wjDbz9s7XwxzDDiwMmRi0MWgIiF /X55IMNdz1befuWeJpgv07zHp6G08BuskV/4YRAlQKe72dbfP+q1JMQ64/H2CvN69MXz /FilvOwefyAP40UBeK5yVNiFGUF8aku3PoPwU04mT/kRFrI6gfyKYBobWFMQqK/TeBq3 q18y3K5SCAhPAQXqXmCgy/5D+iQ7GARgSpCZrWs62Eiyc6B7dzDgfwj0yKwg1+dOEnPN lVvoYD6piWVNEVRyij+mKyJgLrkljzeTCC/nPwiEhmGT6ct64yyHyIKKrOx8iwxQm0fV UR4Q== X-Gm-Message-State: ABuFfohD3hKj3s40RjU790oHkyKB+uDPNEEeErt+TNzJmq9nz8yMbJ7B B05PwUPZjj3X1itPX7p3bzjuMhydVBoxTQq4OsQ= X-Google-Smtp-Source: ACcGV633b4ZYM/2u/TPY4nrYS8EQ1EaFO6rVmZIgwK+9T07kJ7doPISgzWfqej1MJQlvPmN+CdYV+jli3XGkevyD3n8= X-Received: by 2002:a1c:8154:: with SMTP id c81-v6mr1961574wmd.140.1539269388968; Thu, 11 Oct 2018 07:49:48 -0700 (PDT) MIME-Version: 1.0 References: <20181011132641.BC838B804DC@rfc-editor.org> In-Reply-To: <20181011132641.BC838B804DC@rfc-editor.org> From: =?UTF-8?Q?Eug=C3=A8ne_Adell?= Date: Thu, 11 Oct 2018 16:49:29 +0200 Message-ID: To: RFC Errata System Cc: turners@ieca.com, tim.polk@nist.gov, Eric Rescorla , iesg@ietf.org, TLS WG Content-Type: multipart/alternative; boundary="00000000000024a7cc0577f51526" Archived-At: X-Mailman-Approved-At: Thu, 11 Oct 2018 08:10:20 -0700 Subject: Re: [TLS] [Errata Rejected] RFC6176 (5520) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 14:49:53 -0000 --00000000000024a7cc0577f51526 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, I know the deficiencies list as reported in this document is not exhaustive but it's worth mentionning this one even in a rejected errata. It had a greater impact than the MITM reset, the latter being mentionned. Le jeu. 11 oct. 2018 =C3=A0 15:27, RFC Errata System a =C3=A9crit : > The following errata report has been rejected for RFC6176, > "Prohibiting Secure Sockets Layer (SSL) Version 2.0". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5520 > > -------------------------------------- > Status: Rejected > Type: Editorial > > Reported by: Eugene Adell > Date Reported: 2018-10-11 > Rejected by: EKR (IESG) > > Section: 2 > > Original Text > ------------- > o Sessions can be easily terminated. A man-in-the-middle can easily > insert a TCP FIN to close the session, and the peer is unable to > determine whether or not it was a legitimate end of the session. > > Corrected Text > -------------- > o Sessions can be easily terminated. A man-in-the-middle can easily > insert a TCP FIN to close the session, and the peer is unable to > determine whether or not it was a legitimate end of the session. > > o The root certificate authority keys are overexposed. The server > sends only one certificate signed by a root certificate authority, > which means a frequent use of this authority keys for signing new > certificates. This use can lead to key loss and the compromise of > all certificates previously signed including the root certificate. > > Notes > ----- > Adding a deficiency. > Recent history showed that well-known authorities could loose their keys > and it had a wide impact on security. > SSL 2.0 limits the certificate handshake message to one single > certificate, thus making it impossible to send a certificate chain. > A certificate chain doesn't completely prevent key loss, but it gives mor= e > protection to the root certificate keys which can be stored and hidden > until we need them again, which is much less often than without chaining. > > > > --VERIFIER NOTES-- > This isn't an error in the original document. It's new text you want t= o > add. > > -------------------------------------- > RFC6176 (draft-ietf-tls-ssl2-must-not-04) > -------------------------------------- > Title : Prohibiting Secure Sockets Layer (SSL) Version 2.0 > Publication Date : March 2011 > Author(s) : S. Turner, T. Polk > Category : PROPOSED STANDARD > Source : Transport Layer Security > Area : Security > Stream : IETF > Verifying Party : IESG > --00000000000024a7cc0577f51526 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, I know the deficiencies list as reported in thi= s document is not exhaustive but it's worth mentionning this one even i= n a rejected errata. It had a greater impact than the MITM reset, the latte= r being mentionned.=C2=A0

Le jeu. 11 oct. 2018 =C3=A0 15:27, RFC Errata System <rfc-editor@rfc-editor.org> a =C3=A9crit= =C2=A0:
The following errata report= has been rejected for RFC6176,
"Prohibiting Secure Sockets Layer (SSL) Version 2.0".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5520

--------------------------------------
Status: Rejected
Type: Editorial

Reported by: Eugene Adell <eugene.adell@gmail.com>
Date Reported: 2018-10-11
Rejected by: EKR (IESG)

Section: 2

Original Text
-------------
=C2=A0 =C2=A0o=C2=A0 Sessions can be easily terminated.=C2=A0 A man-in-the-= middle can easily
=C2=A0 =C2=A0 =C2=A0 insert a TCP FIN to close the session, and the peer is= unable to
=C2=A0 =C2=A0 =C2=A0 determine whether or not it was a legitimate end of th= e session.

Corrected Text
--------------
=C2=A0 =C2=A0o=C2=A0 Sessions can be easily terminated.=C2=A0 A man-in-the-= middle can easily
=C2=A0 =C2=A0 =C2=A0 insert a TCP FIN to close the session, and the peer is= unable to
=C2=A0 =C2=A0 =C2=A0 determine whether or not it was a legitimate end of th= e session.

=C2=A0 =C2=A0o=C2=A0 The root certificate authority keys are overexposed. T= he server
=C2=A0 =C2=A0 =C2=A0 sends only one certificate signed by a root certificat= e authority,
=C2=A0 =C2=A0 =C2=A0 which means a frequent use of this authority keys for = signing new
=C2=A0 =C2=A0 =C2=A0 certificates. This use can lead to key loss and the co= mpromise of
=C2=A0 =C2=A0 =C2=A0 all certificates previously signed including the root = certificate.

Notes
-----
Adding a deficiency.
Recent history showed that well-known authorities could loose their keys an= d it had a wide impact on security.
SSL 2.0 limits the certificate handshake message to one single certificate,= thus making it impossible to send a certificate chain.
A certificate chain doesn't completely prevent key loss, but it gives m= ore protection to the root certificate keys which can be stored and hidden = until we need them again, which is much less often than without chaining.


=C2=A0--VERIFIER NOTES--
=C2=A0 =C2=A0This isn't an error in the original document. It's new= text you want to add.

--------------------------------------
RFC6176 (draft-ietf-tls-ssl2-must-not-04)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Prohibiting S= ecure Sockets Layer (SSL) Version 2.0
Publication Date=C2=A0 =C2=A0 : March 2011
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: S. Turner, T. Polk
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Transport Layer Se= curity
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Security
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
--00000000000024a7cc0577f51526-- From nobody Thu Oct 11 09:17:38 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE440130E1B; Thu, 11 Oct 2018 09:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p91hzQ2TGziZ; Thu, 11 Oct 2018 09:17:35 -0700 (PDT) Received: from mail-it1-f176.google.com (mail-it1-f176.google.com [209.85.166.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0998C130EB9; Thu, 11 Oct 2018 09:17:35 -0700 (PDT) Received: by mail-it1-f176.google.com with SMTP id q70-v6so14359910itb.3; Thu, 11 Oct 2018 09:17:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2Ic2RubtslVXnAIkIKooxzK6Et/wko+iid7vBN0HL5s=; b=Ce91vqBN7do44fgmth1kcbHtKD29DmdgBLIfkHUyfWXBVkmstkLrS7VlKLThY2qNFw 9xoL0Zm6zHbdxeb+y/QtZHtyarJA1wBddl8MlgEfqw5c6ecukGAXqLOWyPn3rFJjJdtx COUw/znjp3z6OrJ/3ii1TRBw0DRDDMc/OD7qypgWHCqSMkpwQmUhiDXHctFkXp4gAq3O 8o64rRpKpe1K84vuJX+agxYtar/sIkJj9rRnGmVIvPgeaKCA0gglK4/HwsFHRvcvQu3M H9yCwDX3n3WuvqG3RutIZBNFeGWiKU4VmQG6j7wmsgDHOvLHHgEDC5497Uh66Szai3l+ NxMw== X-Gm-Message-State: ABuFfoiQEzjkIoDkOATOZQaYriJ3iAbq+d/QCv1JAoG72AnHoO8KZas9 lM+TjyqYtvMr1G1pDQNJclGPQyaM9LTZPA== X-Google-Smtp-Source: ACcGV60w9+olKGnodC9AVUMEl+QYdXhEGS727wR0FliicdsG0aPDxIHdsA6Bqs/8FpxY+8QubDrthQ== X-Received: by 2002:a24:9:: with SMTP id 9-v6mr1878302ita.35.1539274654078; Thu, 11 Oct 2018 09:17:34 -0700 (PDT) Received: from mail-it1-f173.google.com (mail-it1-f173.google.com. [209.85.166.173]) by smtp.gmail.com with ESMTPSA id n5-v6sm6203938ioh.58.2018.10.11.09.17.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Oct 2018 09:17:33 -0700 (PDT) Received: by mail-it1-f173.google.com with SMTP id 134-v6so14367163itz.2; Thu, 11 Oct 2018 09:17:33 -0700 (PDT) X-Received: by 2002:a02:9bc6:: with SMTP id f6-v6mr1747829jal.114.1539274652860; Thu, 11 Oct 2018 09:17:32 -0700 (PDT) MIME-Version: 1.0 References: <20181011132641.BC838B804DC@rfc-editor.org> In-Reply-To: From: Ryan Sleevi Date: Thu, 11 Oct 2018 12:17:21 -0400 X-Gmail-Original-Message-ID: Message-ID: To: eugene.adell@gmail.com Cc: rfc-editor@rfc-editor.org, tim.polk@nist.gov, turners@ieca.com, "tls@ietf.org" , The IESG Content-Type: multipart/alternative; boundary="000000000000e547eb0577f64ee9" Archived-At: Subject: Re: [TLS] [Errata Rejected] RFC6176 (5520) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 16:17:37 -0000 --000000000000e547eb0577f64ee9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You will likely find https://lists.w3.org/Archives/Public/ietf-http-wg/2018OctDec/0013.html useful in explaining the process and purpose of errata, and what it means, in practice, to update the document. This understanding will hopefully make it clear why the errata was rejected. On Thu, Oct 11, 2018 at 11:10 AM Eug=C3=A8ne Adell wrote: > Yes, I know the deficiencies list as reported in this document is not > exhaustive but it's worth mentionning this one even in a rejected errata. > It had a greater impact than the MITM reset, the latter being mentionned. > > Le jeu. 11 oct. 2018 =C3=A0 15:27, RFC Errata System > a =C3=A9crit : > >> The following errata report has been rejected for RFC6176, >> "Prohibiting Secure Sockets Layer (SSL) Version 2.0". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata/eid5520 >> >> -------------------------------------- >> Status: Rejected >> Type: Editorial >> >> Reported by: Eugene Adell >> Date Reported: 2018-10-11 >> Rejected by: EKR (IESG) >> >> Section: 2 >> >> Original Text >> ------------- >> o Sessions can be easily terminated. A man-in-the-middle can easily >> insert a TCP FIN to close the session, and the peer is unable to >> determine whether or not it was a legitimate end of the session. >> >> Corrected Text >> -------------- >> o Sessions can be easily terminated. A man-in-the-middle can easily >> insert a TCP FIN to close the session, and the peer is unable to >> determine whether or not it was a legitimate end of the session. >> >> o The root certificate authority keys are overexposed. The server >> sends only one certificate signed by a root certificate authority, >> which means a frequent use of this authority keys for signing new >> certificates. This use can lead to key loss and the compromise of >> all certificates previously signed including the root certificate. >> >> Notes >> ----- >> Adding a deficiency. >> Recent history showed that well-known authorities could loose their keys >> and it had a wide impact on security. >> SSL 2.0 limits the certificate handshake message to one single >> certificate, thus making it impossible to send a certificate chain. >> A certificate chain doesn't completely prevent key loss, but it gives >> more protection to the root certificate keys which can be stored and hid= den >> until we need them again, which is much less often than without chaining= . >> >> >> >> --VERIFIER NOTES-- >> This isn't an error in the original document. It's new text you want >> to add. >> >> -------------------------------------- >> RFC6176 (draft-ietf-tls-ssl2-must-not-04) >> -------------------------------------- >> Title : Prohibiting Secure Sockets Layer (SSL) Version 2.0 >> Publication Date : March 2011 >> Author(s) : S. Turner, T. Polk >> Category : PROPOSED STANDARD >> Source : Transport Layer Security >> Area : Security >> Stream : IETF >> Verifying Party : IESG >> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000e547eb0577f64ee9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You will likely find=C2=A0https:/= /lists.w3.org/Archives/Public/ietf-http-wg/2018OctDec/0013.html useful = in explaining the process and purpose of errata, and what it means, in prac= tice, to update the document. This understanding will hopefully make it cle= ar why the errata was rejected.

<= div dir=3D"ltr">On Thu, Oct 11, 2018 at 11:10 AM Eug=C3=A8ne Adell <eugene.adell@gmail.com> wrote:=
Yes, I know= the deficiencies list as reported in this document is not exhaustive but i= t's worth mentionning this one even in a rejected errata. It had a grea= ter impact than the MITM reset, the latter being mentionned.=C2=A0

<= div class=3D"gmail_quote">
Le jeu. 11 oct. 2018 =C3=A0 15:2= 7, RFC Errata System <rfc-editor@rfc-editor.org> a =C3=A9crit=C2=A0:
The following errata report has been reject= ed for RFC6176,
"Prohibiting Secure Sockets Layer (SSL) Version 2.0".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5520

--------------------------------------
Status: Rejected
Type: Editorial

Reported by: Eugene Adell <eugene.adell@gmail.com>
Date Reported: 2018-10-11
Rejected by: EKR (IESG)

Section: 2

Original Text
-------------
=C2=A0 =C2=A0o=C2=A0 Sessions can be easily terminated.=C2=A0 A man-in-the-= middle can easily
=C2=A0 =C2=A0 =C2=A0 insert a TCP FIN to close the session, and the peer is= unable to
=C2=A0 =C2=A0 =C2=A0 determine whether or not it was a legitimate end of th= e session.

Corrected Text
--------------
=C2=A0 =C2=A0o=C2=A0 Sessions can be easily terminated.=C2=A0 A man-in-the-= middle can easily
=C2=A0 =C2=A0 =C2=A0 insert a TCP FIN to close the session, and the peer is= unable to
=C2=A0 =C2=A0 =C2=A0 determine whether or not it was a legitimate end of th= e session.

=C2=A0 =C2=A0o=C2=A0 The root certificate authority keys are overexposed. T= he server
=C2=A0 =C2=A0 =C2=A0 sends only one certificate signed by a root certificat= e authority,
=C2=A0 =C2=A0 =C2=A0 which means a frequent use of this authority keys for = signing new
=C2=A0 =C2=A0 =C2=A0 certificates. This use can lead to key loss and the co= mpromise of
=C2=A0 =C2=A0 =C2=A0 all certificates previously signed including the root = certificate.

Notes
-----
Adding a deficiency.
Recent history showed that well-known authorities could loose their keys an= d it had a wide impact on security.
SSL 2.0 limits the certificate handshake message to one single certificate,= thus making it impossible to send a certificate chain.
A certificate chain doesn't completely prevent key loss, but it gives m= ore protection to the root certificate keys which can be stored and hidden = until we need them again, which is much less often than without chaining.


=C2=A0--VERIFIER NOTES--
=C2=A0 =C2=A0This isn't an error in the original document. It's new= text you want to add.

--------------------------------------
RFC6176 (draft-ietf-tls-ssl2-must-not-04)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Prohibiting S= ecure Sockets Layer (SSL) Version 2.0
Publication Date=C2=A0 =C2=A0 : March 2011
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: S. Turner, T. Polk
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Transport Layer Se= curity
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Security
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000e547eb0577f64ee9-- From nobody Fri Oct 12 12:49:15 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 794A0130DC8 for ; Fri, 12 Oct 2018 12:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.25 X-Spam-Level: X-Spam-Status: No, score=-9.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhZ19oF07bDZ for ; Fri, 12 Oct 2018 12:49:11 -0700 (PDT) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A7181286E3 for ; Fri, 12 Oct 2018 12:49:11 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id v68-v6so8377450qka.2 for ; Fri, 12 Oct 2018 12:49:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=sgJlHeLYmKwmGKJTFbE/3pGAtYOn/tOKPDGb3rpbe6g=; b=At+3Jhuz/1QdVtqA+NElVgkPqoEHlsKGq+bJkdOKKVI2dPjZgjPpNpvugP/ggZ/Yai kHLZWzc3glx1m0UyhTuctq2a1BpeBmISZQQgT/kaRKseO6AO+YJxyX0pLdPZTnIvFah/ ySTH8o0x3SNWeVq49gUGk6WObOmcYAqEOkSQk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=sgJlHeLYmKwmGKJTFbE/3pGAtYOn/tOKPDGb3rpbe6g=; b=RLqlAJggfI67qBT7Qs5Gr8wmmhFBiGeTyezlEMb8D2G4fagTo8oqZIvzUcXz7sme+k P2MYHRqSALJPZkabEm4KmT4v4y2lqIuQWWMlys+j567tqbjO7fmo2ADdCNVbJtTF6d1T 9eP+VyhgZCdpawU9siZw7QNZVH0ymayT//hOD7SIbkdEh0gePwUko6azvUF1QaGbBwYB VVvsKyFJrTea3Z75hI0nje7jEQ2yHhVEM8PVHYW6AQQYDaRIe854lSNn2tfRdRF3zvzk 9l1EcqXrUDY30ZH8Asy0fAPUFfYAVupYyMxlCbZgRQgF37VMQY8pkIn+LGkFXZnjKqj2 59Rg== X-Gm-Message-State: ABuFfoi90+1lJGH7uH011evQW+ZS2lLT/g2VxUeLcUjbH8xFF4NOpeaI MbUH2z0y4qeC6vNtjQwgLh7WD96NFiIHoDP7zcrRIUGxIQ== X-Google-Smtp-Source: ACcGV62u7RgcB+hF0uJzifVA7+uTRHzWlqH7G7ioPk+r+n0D1+Y85ipXbfhKR3OydMbYlvfEvDxlu61wDMVL0y9Ud7s= X-Received: by 2002:a37:4ece:: with SMTP id c197-v6mr7033875qkb.320.1539373750002; Fri, 12 Oct 2018 12:49:10 -0700 (PDT) MIME-Version: 1.0 From: David Benjamin Date: Fri, 12 Oct 2018 14:48:57 -0500 Message-ID: To: "" Cc: "svaldez@chromium.org" , Adam Langley Content-Type: multipart/alternative; boundary="0000000000008c27db05780d61ad" Archived-At: Subject: [TLS] TLS 1.3 updates from Chrome X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 19:49:14 -0000 --0000000000008c27db05780d61ad Content-Type: text/plain; charset="UTF-8" Dear all, The upcoming release of Google Chrome 70 is expected to enable the final version of TLS 1.3. As the release has progressed through our early release channels, we have learned about some deployment issues we would like to share with the community. First, we are aware of some intolerance to the final TLS 1.3 code point, 0x0304. Prerelease versions of OpenSSL 1.1.1, namely -pre6 and earlier, implemented the draft versions of TLS 1.3 incorrectly . Although the draft versions used separate 0x7fxx code points for forward-compatibility, OpenSSL incorrectly also interpreted 0x0304 as a draft version. These servers will respond to a TLS 1.3 ClientHello with a draft version, rather than TLS 1.2, and fail to interoperate. Early adopters of OpenSSL should upgrade to the final 1.1.1 release. Those that cannot upgrade quickly should disable the draft TLS 1.3 in configuration. We do not believe this problem to be widespread and do not intend to delay TLS 1.3 in Chrome for it. Second, TLS 1.3 includes a downgrade signal in the ServerHello random field that could not be deployed in draft versions. This signal strengthens TLS 1.3 connections while remaining fully backwards compatible with TLS 1.2 and earlier. Unfortunately, despite the solid compatibility story, we are observing deployment issues. We believe these are caused by non-compliant TLS-terminating proxies which, rather than generating their own random values, copy the value from the origin server. This behavior is incorrect for all prior versions of TLS. When such a proxy terminates a connection between a TLS 1.3 client and server, the resulting pair of TLS 1.2 connections appear as a downgrade and are rejected. We are aware of two vendors whose products have this bug: Cisco and Palo Alto Networks, although there may be more. We reported the issue to Cisco in December 2017. They released the fix this past August and have published an advisory . Palo Alto Networks recently discovered the issue on their devices and are planning to release PAN-OS 8.1.4, PAN-OS 8.0.14, and PAN-OS 7.1.21 to fix this, tentatively by Nov 30th. As random values in security protocols are there for a reason and assumed to be random by all security analysis, we would advise that all affected vendors treat such flaws as security issues, and not mere functional flaws. Additionally, vendors should note the Protocol Invariants section of RFC 8446, which points out areas historically dense in errors. Due to the above, we will sadly be shipping TLS 1.3 in Chrome 70 with the server-random check temporarily disabled. While we still have downgrade protection via the Finished check, we consider this additional protection an important part of TLS 1.3 and plan on re-enabling it in the near future. Additionally, we are disabling the False Start optimization on connections with the downgrade signal, as False Start skips the Finished check. Note this effectively disables the optimization on affected middleboxes. Vendors should fix the underlying ServerHello random flaw to recover performance. We would recommend other clients considering similar measures to also disable False Start when the signal is present. To that end, we ask that TLS 1.3 server deployments leave the signal enabled on the server. The False-Start-only enforcement is valuable, and the server signal aids client measurement. Compatibility issues can be mitigated instead on the client. David --0000000000008c27db05780d61ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

The upcoming relea= se of Google Chrome 70 is expected to enable the final version of TLS 1.3. = As the release has progressed through our early release channels, we have l= earned about some deployment issues we would like to share with the communi= ty.

First, we are aware of some intolerance to the= final TLS 1.3 code point, 0x0304. Prerelease versions of OpenSSL 1.1.1, na= mely -pre6 and earlier, implemented the draft versions of TLS 1.3 incorrectly. Althou= gh the draft versions used separate 0x7fxx code points for forward-compatib= ility, OpenSSL incorrectly also interpreted 0x0304 as a draft version. Thes= e servers will respond to a TLS 1.3 ClientHello with a draft version, rathe= r than TLS 1.2, and fail to interoperate.

Early ad= opters of OpenSSL should upgrade to the final 1.1.1 release. Those that can= not upgrade quickly should disable the draft TLS 1.3 in configuration. We d= o not believe this problem to be widespread and do not intend to delay TLS = 1.3 in Chrome for it.

Second, TLS 1.3 includes a <= a href=3D"https://tools.ietf.org/html/rfc8446#section-4.1.3">downgrade sign= al in the ServerHello random field that could not be deployed in draft = versions. This signal strengthens TLS 1.3 connections while = remaining fully backwards compatible with TLS 1.2 and earlier. Unfortunatel= y, despite the solid compatibility story, we are observing deployment issue= s.

We believe these are caused by non-compliant TL= S-terminating proxies which, rather than generating their own random values= , copy the value from the origin server. This behavior is incorrect for all prior versions of TL= S. When such a proxy terminates a connection between a TLS 1.3 client and s= erver, the resulting pair of TLS 1.2 connections appear as a downgrade and = are rejected.

We are aware of two vendors whose pr= oducts have this bug: Cisco and Palo Alto Networks, although there may be m= ore. We reported the issue to Cisco in December 2017. They released the fix= this past August and have published an advisor= y. Palo Alto Networks recently discovered the issue on their devices an= d are planning to release PAN-OS 8.1.4, PAN-OS 8.0.14, and PAN-OS 7.1.21 to= fix this, tentatively by Nov 30th.

As random valu= es in security protocols are there for a reason and assumed to be random by= all security analysis, we would advise that all affected vendors treat suc= h flaws as security issues, and not mere functional flaws. Additionally, ve= ndors should note the Protocol Invariants section of RFC 8446, which points out areas = historically dense in errors.

Due to the above, we= will sadly be shipping TLS 1.3 in Chrome 70 with the server-random check t= emporarily disabled. While we still have downgrade protection via the Finis= hed check, we consider this additional protection an important part of TLS = 1.3 and plan on re-enabling it in the near future. Additionally, we are dis= abling the False Start = optimization on connections with the downgrade signal, as False Start skips= the Finished check. Note this effectively disables the optimization on aff= ected middleboxes. Vendors should fix the underlying ServerHello random fla= w to recover performance.

We would recommend other= clients considering similar measures to also disable False Start when the = signal is present. To that end, we ask that TLS 1.3 server deployments leav= e the signal enabled on the server. The False-Start-only enforcement is val= uable, and the server signal aids client measurement. Compatibility issues = can be mitigated instead on the client.

David
--0000000000008c27db05780d61ad-- From nobody Fri Oct 12 17:58:29 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66847130EE4 for ; Fri, 12 Oct 2018 17:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKxY_smJvje0 for ; Fri, 12 Oct 2018 17:58:13 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C421130EA9 for ; Fri, 12 Oct 2018 17:58:13 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id e22-v6so15809321qto.6 for ; Fri, 12 Oct 2018 17:58:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:mime-version:subject:message-id:references:to:date; bh=NxY/+PelZtShns1JiTE1dvQY0lZPRPvT4Zmb1kTuTPE=; b=Aspkn6ldqCzz9E9EFaHZg+PNX+HA/R3Bzcmm7IB2AJlKJPxU6P4MKNKqu9q+8ZnXnr A/IedQrsl+Ig57ttNwH1o1tg+t9vVFrAQf7b4fOGxRv+bzipH0sWZhO+EbLxyUadjjZN mMNnV4Xy50xJ27HAYIl8Xohc7CaNlAySpV/9Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=NxY/+PelZtShns1JiTE1dvQY0lZPRPvT4Zmb1kTuTPE=; b=PStkGoKeT0KHByBk7VXX7OWLLtgBoEMqBslG6L5oVJ6q+QyO+BIoLDLvFznEic7Z0c YWEvw6zrsr4h0XMy1pDqttqOpuF4y9dvSQkCDJv2Dv2f7iMscLj8AylmMeW1Q7IgUVhQ kgR6L1M0heBTpDpyT8gjrOkf/8ACNpe6q6GB0TDJiBCtRfllWl808yhjbc/6i3TYkQ6m m0Z66fz6zBK12oueErO+HrZPx4LsFxy2t76wdE9wg/ozN3w08ahOPPuBVox/7am0NeZa nejiMBXY1XEx4X841Kz9FIxolsdGlsLoEhmVbNTWgVZUISwHaGBfPgANqZbaOaQg9ldk BJ7A== X-Gm-Message-State: ABuFfogz48klFC1VFwMFqiQVgOP7OGV2FEYlAPLKbMDuI7qW/lqIpJej 65VkWOxH6+bO2z4cZkKvyQhe/WnvtFs= X-Google-Smtp-Source: ACcGV62BxoM1hTX+wzkPAegajJ+SHDgpcEsvLk9t0JV157PULQOmAa3o1DDMaHDNoCwxfERIVlJaYg== X-Received: by 2002:aed:39e8:: with SMTP id m95-v6mr7750147qte.30.1539392292482; Fri, 12 Oct 2018 17:58:12 -0700 (PDT) Received: from [172.16.0.18] ([96.231.224.191]) by smtp.gmail.com with ESMTPSA id y50-v6sm1355975qta.60.2018.10.12.17.58.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Oct 2018 17:58:11 -0700 (PDT) From: Sean Turner Content-Type: multipart/alternative; boundary="Apple-Mail=_64617D98-E266-420B-A55B-3193F93D8087" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <117F2544-6FC3-4D9D-A31C-787F914916E2@sn3rd.com> References: <153938255773.29257.10827766621859025576.idtracker@ietfa.amsl.com> To: tls@ietf.org Date: Fri, 12 Oct 2018 20:58:10 -0400 X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [TLS] Fwd: IETF 103 Final Agenda X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2018 00:58:28 -0000 --Apple-Mail=_64617D98-E266-420B-A55B-3193F93D8087 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 FYI - our sessions are scheduled for the following times: MONDAY, November 5, 2018 1350-1550 Afternoon Session I Chitlada 2 SEC tls Transport Layer Security WG WEDNESDAY, November 7, 2018 1120-1220 Morning Session II Chitlada 1 SEC tls Transport Layer Security WG spt > Begin forwarded message: >=20 > From: IETF Agenda > Subject: IETF 103 Final Agenda > Date: October 12, 2018 at 18:15:57 EDT > To: "IETF Announcement List" > Cc: recentattendees@ietf.org, ietf@ietf.org, 103all@ietf.org > Reply-To: agenda@ietf.org >=20 > IETF 103 > Bangkok, Thailand > November 3-9, 2018 > Hosts: Huawei and Cisco >=20 > The IETF 103 final agenda is now available.=20 >=20 > https://datatracker.ietf.org/meeting/103/agenda.html > https://datatracker.ietf.org/meeting/103/agenda.txt >=20 > While this is considered the final agenda for printing, changes may be = made to the agenda up until and during the meeting. Updates will be = reflected on the web versions of the agenda.=20 >=20 >=20 > IETF 103 Information: https://www.ietf.org/how/meetings/103/ > Register online at: https://www.ietf.org/how/meetings/register/ >=20 >=20 >=20 > Unofficial Side Meetings >=20 > As communicated back in May = (https://www.ietf.org/mail-archive/web/ietf/current/msg107813.html), the = IESG is running an agenda experiment on Friday of the IETF 103 meeting = week. >=20 > Monday through Thursday, we will have two rooms available for = attendees to reserve for side meetings, as usual. On Friday, because = there will be no working group meetings, we will have eight rooms = available for unofficial side meetings. Projectors will be provided in = all of the meeting rooms. Meetecho will not be recording or providing = remote participation on Friday. Please note that all side meetings must = conclude by 13:30. >=20 > We realize that keeping track of all of these side meetings may prove = challenging, so a calendar with subscription details can be found here: = https://www.ietf.org/how/meetings/103/side-meetings/ >=20 >=20 >=20 > Don=E2=80=99t forget to register for these exciting IETF 103 events! >=20 > Hackathon=20 > Signup: = https://www.ietf.org/registration/ietf103/hackathonregistration.py > More information: = https://www.ietf.org/how/runningcode/hackathons/103-hackathon/ > Keep up to date by subscribing to:=20 > https://www.ietf.org/mailman/listinfo/hackathon >=20 > Code Sprint > Signup: = https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF103SprintSignUp > More information: = https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF103Sprint >=20 --Apple-Mail=_64617D98-E266-420B-A55B-3193F93D8087 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 FYI = - our sessions are scheduled for the following times:

MONDAY, November 5, =
2018
1350-1550  Afternoon Session I
Chitlada 2      	SEC 	tls  Transport Layer Security WG

WEDNESDAY, November 7, 2018
1120-1220  Morning Session II
Chitlada 1      	SEC 	tls  Transport Layer Security WG

spt
Begin forwarded = message:

From: = IETF Agenda <agenda@ietf.org>
Subject: = IETF 103 Final = Agenda
Date: = October 12, 2018 at 18:15:57 = EDT
To: = "IETF Announcement List" <ietf-announce@ietf.org>
Cc: recentattendees@ietf.org, ietf@ietf.org, 103all@ietf.org
Reply-To: = agenda@ietf.org

IETF 103
Bangkok, Thailand
November= 3-9, 2018
Hosts: Huawei and Cisco

The IETF 103 final agenda is now available.

https://datatracker.ietf.org/meeting/103/agenda.html
https://datatracker.ietf.org/meeting/103/agenda.txt

While this is considered the final agenda for = printing, changes may be made to the agenda up until and during the = meeting. Updates will be reflected on the web versions of the agenda. =


IETF 103 Information: = https://www.ietf.org/how/meetings/103/
Register online at: = https://www.ietf.org/how/meetings/register/



Unofficial Side Meetings

As communicated back in May = (https://www.ietf.org/mail-archive/web/ietf/current/msg107813.html), = the IESG is running an agenda experiment on Friday of the IETF 103 = meeting week.

Monday through Thursday, we = will have two rooms available for attendees to reserve for side = meetings, as usual. On Friday, because there will be no working group = meetings, we will have eight rooms available for unofficial side = meetings. Projectors will be provided in all of the meeting rooms. = Meetecho will not be recording or providing remote participation on = Friday. Please note that all side meetings must conclude by 13:30.

We realize that keeping track of all of these = side meetings may prove challenging, so a calendar with subscription = details can be found here: = https://www.ietf.org/how/meetings/103/side-meetings/



Don=E2=80=99t forget to = register for these exciting IETF 103 events!

Hackathon
Signup: = https://www.ietf.org/registration/ietf103/hackathonregistration.py
= More information: = https://www.ietf.org/how/runningcode/hackathons/103-hackathon/
= Keep up to date by subscribing to:
= https://www.ietf.org/mailman/listinfo/hackathon

Code Sprint
Signup: = https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF103SprintSignUp
= More information: = https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF103Sprint


= --Apple-Mail=_64617D98-E266-420B-A55B-3193F93D8087-- From nobody Sun Oct 14 01:38:13 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F11A130DD6 for ; Sun, 14 Oct 2018 01:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.622 X-Spam-Level: X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpq95CxlR5NF for ; Sun, 14 Oct 2018 01:38:08 -0700 (PDT) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89790130DD2 for ; Sun, 14 Oct 2018 01:38:07 -0700 (PDT) Received: from computer ([2a02:8109:83c0:4bfd:aade:c5c7:26b2:2c2d]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 256bits, ECDHE-RSA-AES256-GCM-SHA384) by zucker.schokokeks.org with ESMTPSA; Sun, 14 Oct 2018 10:38:05 +0200 id 0000000000000099.000000005BC3006D.00004EA7 Date: Sun, 14 Oct 2018 10:38:18 +0200 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: tls@ietf.org Message-ID: <20181014103818.2c2c0b13@computer> In-Reply-To: References: X-Mailer: Claws Mail 3.17.1 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] TLS 1.3 updates from Chrome X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2018 08:38:12 -0000 Hi, Thanks for that interesting explanation. I just learned about another TLS 1.3 "intolerance" issue that people deploying it should be aware of: It seems some servers don't consider TLS 1.3 cipher suites as "safe" for HTTP/2 and this breaks connections: https://bugzilla.mozilla.org/show_bug.cgi?id=3D1488240#c39 While HTTP/2 is not necessarily the focus of this group I wonder what that means, how HTTP/2 implementations should be made future proof and if there can be a GREASE-like mechanism for it. Whitelisting "safe" ciphers seems to be a bad idea and almost inevitably will lead to more trouble in the future. --=20 Hanno B=C3=B6ck https://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 From nobody Sun Oct 14 06:14:48 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51167129AB8 for ; Sun, 14 Oct 2018 06:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNgchJKAX6j8 for ; Sun, 14 Oct 2018 06:14:45 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B4B91293FB for ; Sun, 14 Oct 2018 06:14:45 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id r83-v6so15087819ljr.7 for ; Sun, 14 Oct 2018 06:14:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oSCvCKeOY1yug5OT4AgZ+rvPZ95Edx8Q21xoDf84vdE=; b=EtbR1RRXVx3geQUSJtGDBN1BN5CXcjluqwtWb9xktYGuHByyyXFzHeskhT4A5Zr7Q6 yIWUoOWlnkpVyBGRpu0qUxrXjCApcL1gKUIaZTI0q1/mS+m1DQOLoHr6pUlkD9dWyz+7 kIyVnxki3hPjoManhBKmN52OD2BKmkYATWsiUA4nFWpCdTd3rXH2D16yk3yMKtv1gxcL ++Bn8qptHGQj1UsRKKIr+1Widp1l2Jdz65qYVsg4BqSgWUEYASz01UHN0TNVnFOluDpr tvrVN2e5K9/jv8CyEZrLh/WJf/01dZYW5Ik2zfZA64wrEbQkbBp/edk4ys1eZzTEEiKR /Y5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oSCvCKeOY1yug5OT4AgZ+rvPZ95Edx8Q21xoDf84vdE=; b=WVX8LozYxK3hYray6N27IoYnLWqJE8gTuZ/vIubnJFAl3I9l+QNQtncF0fjdZWuuEb bJbiRO+e/AZUMOL2EutFH4D5snH2a/Yl3W43/m+SQE/kXCwspp0WTGFljqkq70hvp+Hc Xo1gHx8pYin6r79KL94By7BZLE43rMXSWANiHLkbV/C0XSetttR5i7f4h+iq1mlBYNCa imvrKcSIT6dgrthBIJ7xK4fBhEtcRmh1HonWB+REjkmrfD0GRAUsycT1uxF3Q9TS8wAt bsBlezPoj7FjAUdSpHudgbiIwOTeacYvePlQgZeggKjcfMm/V9o5850f8KfQdy362DkL QqJQ== X-Gm-Message-State: ABuFfohx2K9Zahu0gn7DR2QHboRNoPc2J0/zcH9RCT0CMvxFdJCkkZgB KVyEmtmJOJhZ4ly7MkmJ7S8lPO7Brad7N6tMUE0iZ+H0 X-Google-Smtp-Source: ACcGV61PKbPlsUEiILJ+iQ7Sth1Lh4CsuMBl5E53htIg1/tPsPkozzvZTVz7J2mtHjyRZYDRkj5MvR7ns/T0lqUTBiw= X-Received: by 2002:a2e:544f:: with SMTP id y15-v6mr9136694ljd.51.1539522883559; Sun, 14 Oct 2018 06:14:43 -0700 (PDT) MIME-Version: 1.0 References: <20181014103818.2c2c0b13@computer> In-Reply-To: <20181014103818.2c2c0b13@computer> From: Eric Rescorla Date: Sun, 14 Oct 2018 06:14:06 -0700 Message-ID: To: =?UTF-8?Q?Hanno_B=C3=B6ck?= Cc: "" Content-Type: multipart/alternative; boundary="0000000000009935200578301aa1" Archived-At: Subject: Re: [TLS] TLS 1.3 updates from Chrome X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2018 13:14:47 -0000 --0000000000009935200578301aa1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Oct 14, 2018 at 1:38 AM Hanno B=C3=B6ck wrote: > Hi, > > Thanks for that interesting explanation. > > I just learned about another TLS 1.3 "intolerance" issue that people > deploying it should be aware of: It seems some servers don't consider > TLS 1.3 cipher suites as "safe" for HTTP/2 and this breaks connections: > https://bugzilla.mozilla.org/show_bug.cgi?id=3D1488240#c39 FWIW, I think this may have just been a defect in one provider . > While HTTP/2 is not necessarily the focus of this group I wonder what > that means, how HTTP/2 implementations should be made future proof and > if there can be a GREASE-like mechanism for it. > Whitelisting "safe" ciphers seems to be a bad idea and almost > inevitably will lead to more trouble in the future. > HTTP/2 was pretty careful to phrase this as a black list of unsafe ciphers, so while I agree that whatever happened here was bad, I'm not quite sure how RFC 7540 could have been written to make it less likely... -Ekr --=20 > Hanno B=C3=B6ck > https://hboeck.de/ > > mail/jabber: hanno@hboeck.de > GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000009935200578301aa1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun= , Oct 14, 2018 at 1:38 AM Hanno B=C3=B6ck <hanno@hboeck.de> wrote:
https://bugzilla.mozilla.org/show_bug.cgi= ?id=3D1488240#c39

FWIW, I think this ma= y have just been a defect in one provider .

=C2=A0=
While HTTP/2 is not necessarily the focus of this group I wonder what
that means, how HTTP/2 implementations should be made future proof and
if there can be a GREASE-like mechanism for it.
Whitelisting "safe" ciphers seems to be a bad idea and almost
inevitably will lead to more trouble in the future.
HTTP/2 was pretty careful to phrase this as a black list of un= safe ciphers,
so while I agree that whatever happened here was ba= d, I'm not quite
sure how RFC 7540 could have been written to= make it less likely...

-Ekr


--
Hanno B=C3=B6ck
https:/= /hboeck.de/

mail/jabber: hanno@hbo= eck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000009935200578301aa1-- From nobody Mon Oct 15 13:20:36 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B73130ED6 for ; Mon, 15 Oct 2018 13:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=bartschnet.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtcoiqYn0z-H for ; Mon, 15 Oct 2018 13:20:31 -0700 (PDT) Received: from mail.core-networks.de (mail.core-networks.de [IPv6:2001:1bc0:d::4:9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 332E0130ED3 for ; Mon, 15 Oct 2018 13:20:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bartschnet.de; s=2018030201; h=Content-Transfer-Encoding:MIME-Version:Date: Message-ID:Subject:From:To:content-disposition; bh=B/vE5hyOPTmPU/RbwDi3aSfhQJ1eCxmjDV6W5aLTRCY=; b=dEp2VDrK31A77DntHn7iwTd9hy bRt0cjqUosEiBPl3YTYyvRN5pfFUjmHdnQtTWvdOFcV9JFsKfnPRyDyN3prAOgzh3uQDXqrXDTGK2 VX/HiYmXikdtZj/iR5FEMXM6FFKpC58/S2w/QZI+F1gntq7ykdoNalVuIC50pVkwTILCEsYRaXeH8 dVQPFHFNEiXRmODWBcfwcpk2ASIAFkvl+oHxoxFURC2xFEnUyn7ZuQNgnK2RFjS8nesLSnPOfn/0O UXWJbYTs7kdIRZGKIWG/y2/WVBVWUxjrhoNT5wZbJZTS2pe2bW3mjypTZr8QxKA3XhYJausGVsp/5 vIHGCH0xdY7Vc2C71gwWcqeOzbd1D2ZsFWGSrJdKYYjqSiXQhAGx+fe3fdGmpEsZt5Z5ra/0LaaNK 3cV1LWTYPJLAHUO7cCaSPTR3SM72EzCVfXZM9ahTrkRYf+3CLs2m3K3/e6lLtrIQHMy29tjEV3NaZ dPldTnxQiqZiU7Rkmm84BY5IcYqFRW4uA8dHekJPJ33AedwzysSI75LoLGdj4ZRl33adsWVS3oeXD afHppdF1C6tsz5+noGCSa9RCJ8CE1qXEB17HWEKdqhDpN1hTcr06kuShxG6A/e1jKwVMbTgxPYctB AhpKD1RREgBLdyqLg3jVd7MEyaUMc+4LKB6rbX8ZY=; Received: from localhost (localhost [127.0.0.1]) by mail.core-networks.de id 1gC9Ll-00064R-Bw with ESMTPSA (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) for tls@ietf.org; Mon, 15 Oct 2018 22:20:26 +0200 To: tls@ietf.org From: "Rene 'Renne' Bartsch, B.Sc. Informatics" Message-ID: <90e2851e-6469-226c-b2bd-63efebdfd796@bartschnet.de> Date: Mon, 15 Oct 2018 22:20:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-DE Content-Transfer-Encoding: 7bit Archived-At: Subject: [TLS] Make DANE-TLS (RFC 6698) mandatory for TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 20:20:34 -0000 Hi, TLS is prone to Man-In-The-Middle attacks with unjustly obtained intermediate certificates (e.g. firewall appliances). The DNSSEC KSK-rollover worked like a charm. So I suggest to make DANE-TLS mandatory for TLS to prevent Man-In-The-Middle attacks with unjustly obtained intermediate certificates. Regards, Renne From nobody Mon Oct 15 13:49:44 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC73130F1A for ; Mon, 15 Oct 2018 13:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dl1-spVZbqd for ; Mon, 15 Oct 2018 13:49:27 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7E2D130EFA for ; Mon, 15 Oct 2018 13:49:27 -0700 (PDT) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id C9F2E16DAF for ; Mon, 15 Oct 2018 16:49:25 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Viktor Dukhovni In-Reply-To: <90e2851e-6469-226c-b2bd-63efebdfd796@bartschnet.de> Date: Mon, 15 Oct 2018 16:49:21 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: "" Message-Id: <9700FD81-5DDF-4A14-B740-1216A749510D@dukhovni.org> References: <90e2851e-6469-226c-b2bd-63efebdfd796@bartschnet.de> To: "" X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [TLS] Make DANE-TLS (RFC 6698) mandatory for TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 20:49:42 -0000 Though I am generally an advocate for DANE, and have done much work to further its adoption, this is not a realistic proposal. DANE adoption in TLS will be incremental and will not be accomplished via a mandate. > On Oct 15, 2018, at 4:20 PM, Rene 'Renne' Bartsch, B.Sc. Informatics = wrote: >=20 > TLS is prone to Man-In-The-Middle attacks with unjustly obtained = intermediate certificates (e.g. firewall appliances). > The DNSSEC KSK-rollover worked like a charm. >=20 > So I suggest to make DANE-TLS mandatory for TLS to prevent = Man-In-The-Middle attacks with unjustly obtained intermediate = certificates. If you want to see more DANE deployment, work on tooling to ease DNSSEC deployment, convince registries to support CDS and CDS0, simplify zone signing and key rollover interfaces in nameserver implementations, develop monitoring tools, ... Get efforts to improve the tools funded, ... There is much work to be done, before we can expect ubiquitous DNSSEC support, let alone DANE. DNSSEC deployment is concentrated at domains hosted by providers who have invested in automating it. To bring it to the masses, it must be something that works out of the box. Until then it should be possible to use DNSSEC and DANE with TLS, but we're quite far from being in a position to mandate their use. --=20 Viktor. From nobody Mon Oct 15 18:45:37 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD0F1277BB for ; Mon, 15 Oct 2018 18:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eo1u3RT7INIh for ; Mon, 15 Oct 2018 18:45:33 -0700 (PDT) Received: from mail-it1-f175.google.com (mail-it1-f175.google.com [209.85.166.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA731127333 for ; Mon, 15 Oct 2018 18:45:33 -0700 (PDT) Received: by mail-it1-f175.google.com with SMTP id 74-v6so31286491itw.1 for ; Mon, 15 Oct 2018 18:45:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=iuxh+bshbhx5c64SJWm365PjqWlx3Wg00cPBuzTlJAM=; b=lRg6TzNshdLJYmsIUhWk4w/F/3FS4g+lpUE3xcYQL+MrbDoGIyO2O/UXXzAZ4KZWs+ uM0N1jW0MvDQ5kGsgIHCZ03KbFSgx0xq0sDLMgBb3mCZesA1LIq+Xd6W9IkBthPDQraw fg03JDw6gbYn2zLershkQbDW/pZTmThqlDUSLfL4G8t56czKLo8wYxJ3bIacxrYdXQ8M lO94Bal1+MVONDYNU3EafNNy8uuX+BRzuT4p19BPR3sfAMS86DOJMV4CU4Jm5BvvfIAG mScaA6JL0226WpU1ypnh92ICyma3MNRNhnrF1DBtIIm4uhUa9T1bLCSVJChicV8TlvN+ H0OQ== X-Gm-Message-State: ABuFfogOsoXieugs+4gs0C7Fib8YeD8gHbtRhnWtE/ZR8D+R7hzh+43O AHYla3EAG5ZvwhIyWregnG2+43GFjBk= X-Google-Smtp-Source: ACcGV63IIEjt7nqnaDsgIkSPWEjew3lUxpz8wlC7hh8lWMd2gK3co7T+poRWujyFuakjim0Ow2dXZA== X-Received: by 2002:a24:7305:: with SMTP id y5-v6mr16480555itb.107.1539654332583; Mon, 15 Oct 2018 18:45:32 -0700 (PDT) Received: from mail-it1-f171.google.com (mail-it1-f171.google.com. [209.85.166.171]) by smtp.gmail.com with ESMTPSA id y23-v6sm16582344itc.0.2018.10.15.18.45.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Oct 2018 18:45:32 -0700 (PDT) Received: by mail-it1-f171.google.com with SMTP id q70-v6so31286925itb.3 for ; Mon, 15 Oct 2018 18:45:32 -0700 (PDT) X-Received: by 2002:a24:9302:: with SMTP id y2-v6mr14158542itd.49.1539654331736; Mon, 15 Oct 2018 18:45:31 -0700 (PDT) MIME-Version: 1.0 References: <90e2851e-6469-226c-b2bd-63efebdfd796@bartschnet.de> <9700FD81-5DDF-4A14-B740-1216A749510D@dukhovni.org> In-Reply-To: <9700FD81-5DDF-4A14-B740-1216A749510D@dukhovni.org> From: Ryan Sleevi Date: Mon, 15 Oct 2018 21:44:10 -0400 X-Gmail-Original-Message-ID: Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000852a3c05784eb59d" Archived-At: Subject: Re: [TLS] Make DANE-TLS (RFC 6698) mandatory for TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 01:45:35 -0000 --000000000000852a3c05784eb59d Content-Type: text/plain; charset="UTF-8" On Mon, Oct 15, 2018 at 4:50 PM Viktor Dukhovni wrote: > Though I am generally an advocate for DANE, and have done much work to > further its adoption, this is not a realistic proposal. DANE adoption > in TLS will be incremental and will not be accomplished via a mandate. > > > On Oct 15, 2018, at 4:20 PM, Rene 'Renne' Bartsch, B.Sc. Informatics > wrote: > > > > TLS is prone to Man-In-The-Middle attacks with unjustly obtained > intermediate certificates (e.g. firewall appliances). > > The DNSSEC KSK-rollover worked like a charm. > > > > So I suggest to make DANE-TLS mandatory for TLS to prevent > Man-In-The-Middle attacks with unjustly obtained intermediate certificates. > I think there's another criticism to be leveled at this proposal, and it's suitability for this WG - the motivation stated (firewall appliances) is a question about local policy. I admit my own ignorance here, in that I'm not sure how https://tools.ietf.org/html/draft-nottingham-for-the-users has been progressing as a comparable alternative to the HTML Priority of Constituencies. However, as engineers, we need to recognize that no matter what is memorialized by the IETF, if you have control over the machine - as these enterprises inevitably do to install their firewall appliance - all bets are off. We should not pretend we will prevent that, nor should we increase costs for the ecosystem in pursuit of that effort. --000000000000852a3c05784eb59d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Oct 15, 2018 at 4:50 PM Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
Though I am generally a= n advocate for DANE, and have done much work to
further its adoption, this is not a realistic proposal.=C2=A0 DANE adoption=
in TLS will be incremental and will not be accomplished via a mandate.

> On Oct 15, 2018, at 4:20 PM, Rene 'Renne' Bartsch, B.Sc. Infor= matics <ietf=3D40bartschnet.de@dmarc.ietf.org> wrote:
>
> TLS is prone to Man-In-The-Middle attacks with unjustly obtained inter= mediate certificates (e.g. firewall appliances).
> The DNSSEC KSK-rollover worked like a charm.
>
> So I suggest to make DANE-TLS mandatory for TLS to prevent Man-In-The-= Middle attacks with unjustly obtained intermediate certificates.

I think there's another criticism to be level= ed at this proposal, and it's suitability for this WG - the motivation = stated (firewall appliances) is a question about local policy. I admit my o= wn ignorance here, in that I'm not sure how=C2=A0https://tools.ietf.org/htm= l/draft-nottingham-for-the-users has been progressing as a comparable a= lternative to the HTML Priority of Constituencies.=C2=A0However, as enginee= rs, we need to recognize that no matter what is memorialized by the IETF, i= f you have control over the machine - as these enterprises inevitably do to= install their firewall appliance - all bets are off. We should not pretend= we will prevent that, nor should we increase costs for the ecosystem in pu= rsuit of that effort.
--000000000000852a3c05784eb59d-- From nobody Mon Oct 15 23:12:57 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 021DA1292AD; Mon, 15 Oct 2018 23:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3P-YqgfNS1a; Mon, 15 Oct 2018 23:12:47 -0700 (PDT) Received: from albireo.enyo.de (albireo.enyo.de [5.158.152.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FF211277D2; Mon, 15 Oct 2018 23:12:46 -0700 (PDT) Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1gCIau-0002hl-PH; Tue, 16 Oct 2018 06:12:40 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.89) (envelope-from ) id 1gCIVP-00041e-Hf; Tue, 16 Oct 2018 08:06:59 +0200 From: Florian Weimer To: eugene.adell@gmail.com, turners@ieca.com, tim.polk@nist.gov, iesg@ietf.org, tls@ietf.org References: <20181011132641.BC838B804DC@rfc-editor.org> Date: Tue, 16 Oct 2018 08:06:59 +0200 In-Reply-To: <20181011132641.BC838B804DC@rfc-editor.org> (RFC Errata System's message of "Thu, 11 Oct 2018 06:26:41 -0700 (PDT)") Message-ID: <87va62zapo.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [TLS] [Errata Rejected] RFC6176 (5520) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 06:12:50 -0000 * RFC Errata System: > Corrected Text > -------------- > o The root certificate authority keys are overexposed. The server > sends only one certificate signed by a root certificate authority, > which means a frequent use of this authority keys for signing new > certificates. This use can lead to key loss and the compromise of > all certificates previously signed including the root certificate. > > Notes > ----- > Adding a deficiency. > Recent history showed that well-known authorities could loose their keys and it had a wide impact on security. > SSL 2.0 limits the certificate handshake message to one single certificate, thus making it impossible to send a certificate chain. > A certificate chain doesn't completely prevent key loss, but it gives more protection to the root certificate keys which can be stored and hidden until we need them again, which is much less often than without chaining. > > > > --VERIFIER NOTES-- > This isn't an error in the original document. It's new text you want to add. I think it's also historically incorrect. More security problems were caused by the ability to introduce arbitrary intermediate certificates by CAs than by too many direct signing operations with a root CA key. At least for web use, the original model (which does not allow delegation of trust on the CA side) might actually have been more approriate. (On the RA side, delegation is of course technically possible under any model, and it had its share of problems, too.) From nobody Tue Oct 16 01:33:31 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC4B12D4EE for ; Tue, 16 Oct 2018 01:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WssVE_efUzm4 for ; Tue, 16 Oct 2018 01:33:26 -0700 (PDT) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAF1012D4EB for ; Tue, 16 Oct 2018 01:33:26 -0700 (PDT) Received: by mail-qk1-x733.google.com with SMTP id q5-v6so13578725qki.6 for ; Tue, 16 Oct 2018 01:33:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oD7tPpPP8fqC0KxCbsQlxjTzisF0DHcoJ02vuarZB58=; b=yMXZTDeNWPi8M3QVgnNrk0wTAsC/mALEVr307ffOhT4FqO+kNalbCNz9bayGLi4cTZ Kx+0nYX4mzQ+TTLMMWJpTE6IQd4OCth4OQM0do7MDfLRdlTS4k53fX08CWS8GxC40LzD K9ZA5W++yRGc1p19lYoBIhUy1NpHDl1M8+87fpmkW0aSg32vaLx4SMarLYqvPUrx0cSr gTqZ5vuS/fQTPC4OQwpUEooRGyrKX92PaekIK74SSBeU9z4HSjFWI3RcG2LuyS87xmil 5Pv/6dlBUQ+8ICmDMD2depoQFjnuYimjP5QlasOAWbwHX8/QmEwAwPZXSayN7Ri6bita NVew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oD7tPpPP8fqC0KxCbsQlxjTzisF0DHcoJ02vuarZB58=; b=VYn/HC4pSWL3xnURdFw9gwtaTsggfT5y15SRl+p3A5vmx/0GPlDaOw5y0+STDjGgAo pRXtbOwgs5XTkpxinikjTkrMa/+TthOAOQjTMFH4nQrnvP9PWGZGJfpix9vU+yU0C59J m/I2cvRAPWkPnyZJ+VjrrNIsHuDzAQ0Pmm5JKofctX0rbJDs9cIPttHwfu4//QgQvUWQ 2AEpK6QxyhyZeiwBAhe4yEgETSw6briIs7sKURpalNRYnYzu8kyIQWUKK6LD4FKara2r gmy4/LrtY4O4rgiLCCv/XPb57kyhFCjpT052LcqIWizZyvdFvMt1F+e5S30DB1ZrJC0R lCiw== X-Gm-Message-State: ABuFfohUCFXVh2wLJmpm5Ql9pMlwYOchvf9BaiuOzkuZ61m3KTn0SmNu 5HhttcA97MnOjkIdm1QsI1mix/p879P2NlW8Bzqf0/A6QK4QeQ== X-Google-Smtp-Source: ACcGV62fD56CKHGeE7obIL8Pz5VaJ3dpwm00fH0fp8T7K451im2WAzOEmMQu+obJHiaFFccWWDDxevkmZzM/iSe/zig= X-Received: by 2002:a37:bf46:: with SMTP id p67-v6mr20072077qkf.46.1539678805493; Tue, 16 Oct 2018 01:33:25 -0700 (PDT) MIME-Version: 1.0 References: <90e2851e-6469-226c-b2bd-63efebdfd796@bartschnet.de> <9700FD81-5DDF-4A14-B740-1216A749510D@dukhovni.org> In-Reply-To: From: Ted Lemon Date: Tue, 16 Oct 2018 10:32:49 +0200 Message-ID: To: ryan-ietftls@sleevi.com Cc: "" Content-Type: multipart/alternative; boundary="000000000000451cdd0578546883" Archived-At: Subject: Re: [TLS] Make DANE-TLS (RFC 6698) mandatory for TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 08:33:30 -0000 --000000000000451cdd0578546883 Content-Type: text/plain; charset="UTF-8" Not an argument in favor of the proposal, but the issue with firewall certs is not that we would want to override local security policy, but that firewall certs *can* in principle override local security policy, and in principle DANE could be used to prevent that. What is meant by a firewall cert is a cert that's able to sign for any domain; such certs can in principle be obtained by entities other than the operator of the local firewall. We're calling them firewall certs because that's the ostensible reason for their existence, but we shouldn't assume that the name has any power to restrict how they are used. :) On Tue, Oct 16, 2018 at 3:45 AM Ryan Sleevi wrote: > > > On Mon, Oct 15, 2018 at 4:50 PM Viktor Dukhovni > wrote: > >> Though I am generally an advocate for DANE, and have done much work to >> further its adoption, this is not a realistic proposal. DANE adoption >> in TLS will be incremental and will not be accomplished via a mandate. >> >> > On Oct 15, 2018, at 4:20 PM, Rene 'Renne' Bartsch, B.Sc. Informatics >> wrote: >> > >> > TLS is prone to Man-In-The-Middle attacks with unjustly obtained >> intermediate certificates (e.g. firewall appliances). >> > The DNSSEC KSK-rollover worked like a charm. >> > >> > So I suggest to make DANE-TLS mandatory for TLS to prevent >> Man-In-The-Middle attacks with unjustly obtained intermediate certificates. >> > > I think there's another criticism to be leveled at this proposal, and it's > suitability for this WG - the motivation stated (firewall appliances) is a > question about local policy. I admit my own ignorance here, in that I'm not > sure how https://tools.ietf.org/html/draft-nottingham-for-the-users has > been progressing as a comparable alternative to the HTML Priority of > Constituencies. However, as engineers, we need to recognize that no matter > what is memorialized by the IETF, if you have control over the machine - as > these enterprises inevitably do to install their firewall appliance - all > bets are off. We should not pretend we will prevent that, nor should we > increase costs for the ecosystem in pursuit of that effort. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000451cdd0578546883 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Not an argument in favor of the proposal, but the issue wi= th firewall certs is not that we would want to override local security poli= cy, but that firewall certs can=C2=A0in principle override local sec= urity policy, and in principle DANE could be used to prevent that.=C2=A0 = =C2=A0What is meant by a firewall cert is a cert that's able to sign fo= r any domain; such certs can in principle be obtained by entities other tha= n the operator of the local firewall.=C2=A0 =C2=A0We're calling them fi= rewall certs because that's the ostensible reason for their existence, = but we shouldn't assume that the name has any power to restrict how the= y are used. :)

On Tue,= Oct 16, 2018 at 3:45 AM Ryan Sleevi <ryan-ietftls@sleevi.com> wrote:


On Mon, Oct 15, 2018 at 4:50 PM Viktor Dukhovni &l= t;ietf-dane@duk= hovni.org> wrote:
Though I am generally an advocate for DANE, and have done much w= ork to
further its adoption, this is not a realistic proposal.=C2=A0 DANE adoption=
in TLS will be incremental and will not be accomplished via a mandate.

> On Oct 15, 2018, at 4:20 PM, Rene 'Renne' Bartsch, B.Sc. Infor= matics <ietf=3D40bartschnet.de@dmarc.ietf.org> wrote:
>
> TLS is prone to Man-In-The-Middle attacks with unjustly obtained inter= mediate certificates (e.g. firewall appliances).
> The DNSSEC KSK-rollover worked like a charm.
>
> So I suggest to make DANE-TLS mandatory for TLS to prevent Man-In-The-= Middle attacks with unjustly obtained intermediate certificates.

I think there's another criticism to be level= ed at this proposal, and it's suitability for this WG - the motivation = stated (firewall appliances) is a question about local policy. I admit my o= wn ignorance here, in that I'm not sure how=C2=A0https://= tools.ietf.org/html/draft-nottingham-for-the-users has been progressing= as a comparable alternative to the HTML Priority of Constituencies.=C2=A0H= owever, as engineers, we need to recognize that no matter what is memoriali= zed by the IETF, if you have control over the machine - as these enterprise= s inevitably do to install their firewall appliance - all bets are off. We = should not pretend we will prevent that, nor should we increase costs for t= he ecosystem in pursuit of that effort.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000451cdd0578546883-- From nobody Tue Oct 16 07:01:20 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD76130DE8 for ; Tue, 16 Oct 2018 07:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=bartschnet.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJGzeobUn4Oy for ; Tue, 16 Oct 2018 07:01:11 -0700 (PDT) Received: from mail.core-networks.de (mail.core-networks.de [IPv6:2001:1bc0:d::4:9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C42B12D4EE for ; Tue, 16 Oct 2018 07:01:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bartschnet.de; s=2018030201; h=Content-Transfer-Encoding:MIME-Version:Date: Message-ID:From:To:Subject:content-disposition; bh=iB3LkRDSmyfDwbdUJZTasVxSO7sZa5IfN6EpPdtlNPU=; b=VaZmtPMm/lfWwU1AIiyOGaULcN CUllkGqsnmley7Ip7mmO4uGT4BOqHeGckVOc6sGyEqd7jImS/YOl2Oa79T2yjqDeuTjs0CE+dwMKn cT1FYe3MWlhGZtvnoWhmVmEFAzjglsVIzQGB3/HGiAWJLmE7RfMuxN/R77UJKCtIJ0UdXUH3CPXYt A1LdjRpOQ3nyQ1tzhhV3tUQDyYPaWM4vKPdFA5EY7a62ZvRD+oBGl97MQqZGDwrKeyD0JwNLlhfTj afjr4kVgQK71qxBqrl+LDb0xXRwdrhwGtK/auILr94vsIwQD8n3sOSRSUoFrPWmEXtOG8ONWU3J1l vhE+WPfIKDoiPa39WXCGU+lKINGOobA2qWTDajFChUlpddt0JLlkZmPlorSi0f/JyXH+KuEqHB5PQ sAVeSgBjoiFM9m5ewiAzkGtXo31nKRFko+UwaydhgfO6dWYd/DaUoIOF4RHVJztV3ak2/kCIq7V8Y eExxwtySOHUmL3M5qtSuJrchnl9MevDCNch5QIEd5Ji4+mrJ8GIpvzc8fIH6TOtnVUCI5kesYqQtB 1RoUPMazFJ6nI3FYgy2VqsEqlPVj2MW6zl6IcKUE5FwSmbDcd2P/urzxK5GPuYnGG/YGk15hTQ7Pd IG1lf9VMzpQa7Sjd6bhte5ylopCrE2PICh9b3WB7A=; Received: from localhost (localhost [127.0.0.1]) by mail.core-networks.de id 1gCPuD-0000Gf-WA with ESMTPSA (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) for tls@ietf.org; Tue, 16 Oct 2018 16:01:08 +0200 To: tls@ietf.org References: <90e2851e-6469-226c-b2bd-63efebdfd796@bartschnet.de> <9700FD81-5DDF-4A14-B740-1216A749510D@dukhovni.org> From: "Rene 'Renne' Bartsch, B.Sc. Informatics" Message-ID: <652234d7-55da-fea0-e185-6f1264b3fb28@bartschnet.de> Date: Tue, 16 Oct 2018 16:01:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <9700FD81-5DDF-4A14-B740-1216A749510D@dukhovni.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-DE Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Make DANE-TLS (RFC 6698) mandatory for TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 14:01:19 -0000 Unjust certificates can be bought for 150,- $ in the darknet which makes TLS snake-oil. And you never know if the internet provider is hostile or hacked. So we should act in the favor of end-users. If we don't have the position to make DANE mandatory, yet, we should at least try to encourage browser vendors to support DANE. Just think about all the online-banking websites without DNSSEC/DANE protection. Am 15.10.18 um 22:49 schrieb Viktor Dukhovni: > Though I am generally an advocate for DANE, and have done much work to > further its adoption, this is not a realistic proposal. DANE adoption > in TLS will be incremental and will not be accomplished via a mandate. > >> On Oct 15, 2018, at 4:20 PM, Rene 'Renne' Bartsch, B.Sc. Informatics wrote: >> >> TLS is prone to Man-In-The-Middle attacks with unjustly obtained intermediate certificates (e.g. firewall appliances). >> The DNSSEC KSK-rollover worked like a charm. >> >> So I suggest to make DANE-TLS mandatory for TLS to prevent Man-In-The-Middle attacks with unjustly obtained intermediate certificates. > > If you want to see more DANE deployment, work on tooling to ease > DNSSEC deployment, convince registries to support CDS and CDS0, > simplify zone signing and key rollover interfaces in nameserver > implementations, develop monitoring tools, ... Get efforts to > improve the tools funded, ... > > There is much work to be done, before we can expect ubiquitous > DNSSEC support, let alone DANE. DNSSEC deployment is concentrated > at domains hosted by providers who have invested in automating it. > To bring it to the masses, it must be something that works out of > the box. > > Until then it should be possible to use DNSSEC and DANE with TLS, > but we're quite far from being in a position to mandate their use. > From nobody Tue Oct 16 07:06:13 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0F4130DC9 for ; Tue, 16 Oct 2018 07:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LggROcaJPCP for ; Tue, 16 Oct 2018 07:06:10 -0700 (PDT) Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CA8012D4EE for ; Tue, 16 Oct 2018 07:06:10 -0700 (PDT) Received: by mail-oi1-x231.google.com with SMTP id l197-v6so18117955oib.8 for ; Tue, 16 Oct 2018 07:06:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+usZpNddXNgkYUeqrfRZOK1r8VHCtAGjHAfle7tnVqE=; b=HlUMkqq9gdOWiMCaLIsFuf7k01SH94H+GCdhLPY6AXKX16PNMggB1tY4gDY8lZ9RB2 DGMICMUJ+Fd1n0+PoY+oDV94VDKFLuyhfuFJs+w0NRAQtJ4Yq3HoYaNjSYuVIYGngSZw EkEuPnEtJ2A2X/ciJ/Ls5nM/N+/Elqskzr/x7OFGqZ1ovxXOEBkhytT0TkPZ9tcej+ss G2ytYhZM0q1hkE/l2RWau0o9mjzQKYqfh0vl7Yl6mn66KgSOqcAoj2o5fLpPL8+xqK38 gpgAlbpGdvFx9qf99GIqEJHt5LzNd5TvxHmCz8820St7bPHgwZgVD1EpAyxsCjUV0vDg SHrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+usZpNddXNgkYUeqrfRZOK1r8VHCtAGjHAfle7tnVqE=; b=X7b4+hxra3N7UEuhiUei1qtR8z24GSwsb1NRxVTYXpVsbNUpRHd6Xtsr4XXnADSAqd kTHC2Sl0zc5vZe/dB43l4yzZlcipEvtJlxqS7seGLtKr3zdvqfzYkBf3OCSOF4I3NRm/ RwKcCHh8OPHK2m7vvEutkLj6tnuhTzU5Jq8U0hA3VvMNxsysnhbQCpZ49YgpDVC55gjm NrVUBUxlrd0TGM0uKRo6isEb2ALg6QnsGIN1UPurpmqqz5fG8ZZLax11eQ64GKs/cmY/ S5TYPjLdfTAwM8rqFwbq/PUQn2gFBlw2c7m3x7wI4RAASZaqX/KqLJrXSivS+UhBvsee 6m3A== X-Gm-Message-State: ABuFfoiJ/pyM/QoHrH8GfhWg/mtl5W8BJNlMHPYSHsW2+RWQFpMcFPTw ZvH1XapQcmCNIkfCVtwBkqB3cZo269Pz3ptGiE2py3hSnMPL5g== X-Google-Smtp-Source: ACcGV61a3R8T5t1BdJucMEZNeLoM6JZg/GqwU7QgiGD+58nDr668qBEJ2G4EYvGRuooK1c1WNAedaXLXxvtue2zfs6w= X-Received: by 2002:aca:540c:: with SMTP id i12-v6mr12186820oib.49.1539698768170; Tue, 16 Oct 2018 07:06:08 -0700 (PDT) MIME-Version: 1.0 References: <90e2851e-6469-226c-b2bd-63efebdfd796@bartschnet.de> <9700FD81-5DDF-4A14-B740-1216A749510D@dukhovni.org> <652234d7-55da-fea0-e185-6f1264b3fb28@bartschnet.de> In-Reply-To: <652234d7-55da-fea0-e185-6f1264b3fb28@bartschnet.de> From: Richard Barnes Date: Tue, 16 Oct 2018 10:05:49 -0400 Message-ID: To: ietf=40bartschnet.de@dmarc.ietf.org Cc: "" Content-Type: multipart/alternative; boundary="00000000000023628b0578590e07" Archived-At: Subject: Re: [TLS] Make DANE-TLS (RFC 6698) mandatory for TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 14:06:13 -0000 --00000000000023628b0578590e07 Content-Type: text/plain; charset="UTF-8" On Tue, Oct 16, 2018 at 10:02 AM Rene 'Renne' Bartsch, B.Sc. Informatics wrote: > Unjust certificates can be bought for 150,- $ [citation-needed] https://xkcd.com/285/ I'm sure if you could produce such a certificates, the root programs would be happy to investigate how it was caused to be issued. --Richard > in the darknet which makes TLS snake-oil. And you never know if the > internet provider is hostile or hacked. > So we should act in the favor of end-users. If we don't have the position > to make DANE mandatory, yet, we should at least try to encourage browser > vendors > to support DANE. Just think about all the online-banking websites without > DNSSEC/DANE protection. > > > Am 15.10.18 um 22:49 schrieb Viktor Dukhovni: > > Though I am generally an advocate for DANE, and have done much work to > > further its adoption, this is not a realistic proposal. DANE adoption > > in TLS will be incremental and will not be accomplished via a mandate. > > > >> On Oct 15, 2018, at 4:20 PM, Rene 'Renne' Bartsch, B.Sc. Informatics > wrote: > >> > >> TLS is prone to Man-In-The-Middle attacks with unjustly obtained > intermediate certificates (e.g. firewall appliances). > >> The DNSSEC KSK-rollover worked like a charm. > >> > >> So I suggest to make DANE-TLS mandatory for TLS to prevent > Man-In-The-Middle attacks with unjustly obtained intermediate certificates. > > > > If you want to see more DANE deployment, work on tooling to ease > > DNSSEC deployment, convince registries to support CDS and CDS0, > > simplify zone signing and key rollover interfaces in nameserver > > implementations, develop monitoring tools, ... Get efforts to > > improve the tools funded, ... > > > > There is much work to be done, before we can expect ubiquitous > > DNSSEC support, let alone DANE. DNSSEC deployment is concentrated > > at domains hosted by providers who have invested in automating it. > > To bring it to the masses, it must be something that works out of > > the box. > > > > Until then it should be possible to use DNSSEC and DANE with TLS, > > but we're quite far from being in a position to mandate their use. > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00000000000023628b0578590e07 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Oct 16, 2018 at 10:02 AM Rene = 9;Renne' Bartsch, B.Sc. Informatics <ietf=3D40bartschnet.de@dmarc.ietf.org> wrote:
=
https://xkcd.com/285/

I'm = sure if you could produce such a certificates, the root programs would be h= appy to investigate how it was caused to be issued.

--Richard
=C2=A0
in the darknet which makes TLS snake-oil. And you never kn= ow if the internet provider is hostile or hacked.
So we should act in the favor of end-users. If we don't have the positi= on to make DANE mandatory, yet, we should at least try to encourage browser= vendors
to support DANE. Just think about all the online-banking websites without D= NSSEC/DANE protection.


Am 15.10.18 um 22:49 schrieb Viktor Dukhovni:
> Though I am generally an advocate for DANE, and have done much work to=
> further its adoption, this is not a realistic proposal.=C2=A0 DANE ado= ption
> in TLS will be incremental and will not be accomplished via a mandate.=
>
>> On Oct 15, 2018, at 4:20 PM, Rene 'Renne' Bartsch, B.Sc. I= nformatics <ietf=3D40bartschnet.de@dmarc.ietf.org> wrote:
>>
>> TLS is prone to Man-In-The-Middle attacks with unjustly obtained i= ntermediate certificates (e.g. firewall appliances).
>> The DNSSEC KSK-rollover worked like a charm.
>>
>> So I suggest to make DANE-TLS mandatory for TLS to prevent Man-In-= The-Middle attacks with unjustly obtained intermediate certificates.
>
> If you want to see more DANE deployment, work on tooling to ease
> DNSSEC deployment, convince registries to support CDS and CDS0,
> simplify zone signing and key rollover interfaces in nameserver
> implementations, develop monitoring tools, ...=C2=A0 Get efforts to > improve the tools funded, ...
>
> There is much work to be done, before we can expect ubiquitous
> DNSSEC support, let alone DANE.=C2=A0 DNSSEC deployment is concentrate= d
> at domains hosted by providers who have invested in automating it.
> To bring it to the masses, it must be something that works out of
> the box.
>
> Until then it should be possible to use DNSSEC and DANE with TLS,
> but we're quite far from being in a position to mandate their use.=
>

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--00000000000023628b0578590e07-- From nobody Tue Oct 16 07:07:22 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFC2130DEE for ; Tue, 16 Oct 2018 07:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2_rXeHqzJ1p for ; Tue, 16 Oct 2018 07:07:14 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2E71130E09 for ; Tue, 16 Oct 2018 07:07:13 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id 23-v6so14148370qkh.8 for ; Tue, 16 Oct 2018 07:07:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=orQio1MbJftyp9KkuJFXdRgP5LXKNPcCXuQW8VZptRA=; b=WPdKmOg6chTetfNeNzdSjfWKCT2kCmBuVWtbT7wMhcN1Tf1Ighvwbbjm7Mpfg/rw5q FQz9EQ1yYhPuhaJ0T6HjdSXeswe1oPuRNRxaqGsH+j/H8hsKi4mTrOmobPtd+sW3fURV mNUE9N6DoirB+xmuV7uUmCm3xb+KC6bzxg15W/R55kcmVri5+mrb4dVVwwCt6nj/sx65 /2C01XvtccuhpqYjBKJ2sqAmVRCeIOFmpjqvzGfEF3jYMpNTayxccpYUUX58vCKazbr1 pJyKN4r+E9TMUo8kcvktb8OnMrdNSgdyJ47Yy1QGfgDmFZY2IZKtfxP9TWTVWbTO869n FWpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=orQio1MbJftyp9KkuJFXdRgP5LXKNPcCXuQW8VZptRA=; b=dz3lksoVfCraQGzG6YkymsReuqw5uCDIijt19uT/LLU1oBeR4B2wpDpzlu35qLMiIS Xk8FzuEmnJ4M+jjActv7Nlw6ArylerulSjm3xzTtzBJI5SHBXCoNRS7CdMTTiGE1IGj8 2WGp4NoL2QleqgSywRrb+9n6fbhg5noqNNfTE3zTdeHX94fli27XP1Mm4kWFObgBHSYv 83TpnGraa9FNOl/umuKMIpL32sr/kOwS9gfXp5QE5O/bVVM/qAd21DFK2fsMpL06UK7J BJZL/dHZWrIIw0gKmZDmQjKmHiCJUQAOOZ+Dlj0s2+l92mnlm/CdniPCTn3Zthu4CX6v VOsQ== X-Gm-Message-State: ABuFfoi/rnuB5bE2+L7JfmXB4SRYElMU7SOHNL77aTytKhWNkXspGL9+ 6RIhwwkl7MQsY7dPo8PXsVk/tWwLvUJN40wjSWkg69sk9UCPgA== X-Google-Smtp-Source: ACcGV63bHlwyJvcXPTssLc455YCFIxH/5kR8JWLc5XC4+iXWYPj9Ug+w4JivCwSOj1di70sv/H2kLMMSidGZKHhiW/w= X-Received: by 2002:a37:bf46:: with SMTP id p67-v6mr21260150qkf.46.1539698832847; Tue, 16 Oct 2018 07:07:12 -0700 (PDT) MIME-Version: 1.0 References: <90e2851e-6469-226c-b2bd-63efebdfd796@bartschnet.de> <9700FD81-5DDF-4A14-B740-1216A749510D@dukhovni.org> <652234d7-55da-fea0-e185-6f1264b3fb28@bartschnet.de> In-Reply-To: <652234d7-55da-fea0-e185-6f1264b3fb28@bartschnet.de> From: Ted Lemon Date: Tue, 16 Oct 2018 16:06:36 +0200 Message-ID: To: ietf=40bartschnet.de@dmarc.ietf.org Cc: "" Content-Type: multipart/alternative; boundary="000000000000fe529105785911d2" Archived-At: Subject: Re: [TLS] Make DANE-TLS (RFC 6698) mandatory for TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 14:07:21 -0000 --000000000000fe529105785911d2 Content-Type: text/plain; charset="UTF-8" Can you provide a citation for that statement? Not doubting you, particularly, but this is news to me, and probably to some others on this list, if true. On Tue, Oct 16, 2018 at 4:01 PM Rene 'Renne' Bartsch, B.Sc. Informatics wrote: > Unjust certificates can be bought for 150,- $ in the darknet which makes > TLS snake-oil. And you never know if the internet provider is hostile or > hacked. > So we should act in the favor of end-users. If we don't have the position > to make DANE mandatory, yet, we should at least try to encourage browser > vendors > to support DANE. Just think about all the online-banking websites without > DNSSEC/DANE protection. > > > Am 15.10.18 um 22:49 schrieb Viktor Dukhovni: > > Though I am generally an advocate for DANE, and have done much work to > > further its adoption, this is not a realistic proposal. DANE adoption > > in TLS will be incremental and will not be accomplished via a mandate. > > > >> On Oct 15, 2018, at 4:20 PM, Rene 'Renne' Bartsch, B.Sc. Informatics > wrote: > >> > >> TLS is prone to Man-In-The-Middle attacks with unjustly obtained > intermediate certificates (e.g. firewall appliances). > >> The DNSSEC KSK-rollover worked like a charm. > >> > >> So I suggest to make DANE-TLS mandatory for TLS to prevent > Man-In-The-Middle attacks with unjustly obtained intermediate certificates. > > > > If you want to see more DANE deployment, work on tooling to ease > > DNSSEC deployment, convince registries to support CDS and CDS0, > > simplify zone signing and key rollover interfaces in nameserver > > implementations, develop monitoring tools, ... Get efforts to > > improve the tools funded, ... > > > > There is much work to be done, before we can expect ubiquitous > > DNSSEC support, let alone DANE. DNSSEC deployment is concentrated > > at domains hosted by providers who have invested in automating it. > > To bring it to the masses, it must be something that works out of > > the box. > > > > Until then it should be possible to use DNSSEC and DANE with TLS, > > but we're quite far from being in a position to mandate their use. > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000fe529105785911d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Can you provide a citation for that statement?=C2=A0 =C2= =A0Not doubting you, particularly, but this is news to me, and probably to = some others on this list, if true.

On Tue, Oct 16, 2018 at 4:01 PM Rene 'Renne' Bartsch, = B.Sc. Informatics <ietf=3D40bartschnet.de@dmarc.ietf.org> wrote:
Unjust certificates can be bought for 150,- $ in the darknet= which makes TLS snake-oil. And you never know if the internet provider is = hostile or hacked.
So we should act in the favor of end-users. If we don't have the positi= on to make DANE mandatory, yet, we should at least try to encourage browser= vendors
to support DANE. Just think about all the online-banking websites without D= NSSEC/DANE protection.


Am 15.10.18 um 22:49 schrieb Viktor Dukhovni:
> Though I am generally an advocate for DANE, and have done much work to=
> further its adoption, this is not a realistic proposal.=C2=A0 DANE ado= ption
> in TLS will be incremental and will not be accomplished via a mandate.=
>
>> On Oct 15, 2018, at 4:20 PM, Rene 'Renne' Bartsch, B.Sc. I= nformatics <ietf=3D40bartschnet.de@dmarc.ietf.org> wrote:
>>
>> TLS is prone to Man-In-The-Middle attacks with unjustly obtained i= ntermediate certificates (e.g. firewall appliances).
>> The DNSSEC KSK-rollover worked like a charm.
>>
>> So I suggest to make DANE-TLS mandatory for TLS to prevent Man-In-= The-Middle attacks with unjustly obtained intermediate certificates.
>
> If you want to see more DANE deployment, work on tooling to ease
> DNSSEC deployment, convince registries to support CDS and CDS0,
> simplify zone signing and key rollover interfaces in nameserver
> implementations, develop monitoring tools, ...=C2=A0 Get efforts to > improve the tools funded, ...
>
> There is much work to be done, before we can expect ubiquitous
> DNSSEC support, let alone DANE.=C2=A0 DNSSEC deployment is concentrate= d
> at domains hosted by providers who have invested in automating it.
> To bring it to the masses, it must be something that works out of
> the box.
>
> Until then it should be possible to use DNSSEC and DANE with TLS,
> but we're quite far from being in a position to mandate their use.=
>

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000fe529105785911d2-- From nobody Tue Oct 16 07:59:58 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFC98130DE9 for ; Tue, 16 Oct 2018 07:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=bartschnet.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcsYwG8qYVOm for ; Tue, 16 Oct 2018 07:59:54 -0700 (PDT) Received: from mail.core-networks.de (mail.core-networks.de [IPv6:2001:1bc0:d::4:9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC26712D4EE for ; Tue, 16 Oct 2018 07:59:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bartschnet.de; s=2018030201; h=Content-Transfer-Encoding:MIME-Version:Date: Message-ID:From:Subject:to:content-disposition; bh=wk7VvHA8aCDfslIzAdrIwJ4auoHnW7Ci1moEB+LNGks=; b=VZYxdZRHNCijHFLLcgahgVXPOM gtz5HdRp/z5asYWNL1k458Hs4r1PPgIpPK2gs0LkOIl0IGXdvNzwS1SVx4VvCTrbnJO78VU94++YP vIcHVmwc+ZWlfBHk4gUUpcsPYuONpoHDruQ+l8rU6e6+OunUZD2o3I38wrnL3Shukxqi9X9dYF2Tg ZRdO/yFO+WY+7sYVNRu5TKZc6Fd+5zv7T7V9C8hjavNugGragH8SJhgzwNGFvS4HhEB5UhUuuDNbg p1+tpPMniHFMRaPz/WxXCw+zY7kfJ5mq2d2ecNUoOZOAjOm8ZpZT17t5C+Z6cy3fKy80MqjcGtfRJ 3aQDujrKUm2KGDy8vVQ9HdfPslZKn6fS4wI8QrXI+E/6q6EhTQMr2hzrgc9Fq9a3G+7NbgUPd1jZM I6dR9VsOiA8hUt135ws38T+qjtYJNLSYj5p/SBLjD/Zpe7qo76Mu0F7oWBAgiyTXcYMNeQ1XT4Uzf VsIPQc9SkNbomHYW/vRxPvs9FxLkpM8Vt0CX+GjImLc+k8Ch9Ioku1uYI/XqnMHMyL9esALic6F2P 0XhAi+9bGIGt5FAWDWHX/LIZxLHPOt1euh2oq+cUyPWTZq7T2KGFYyRAc5WPymL7jJO/Bp00UG7IP rr3/XY1Bl65nI6WFmtdsxIaxZesPK7apKTqH1BRvA=; Received: from localhost (localhost [127.0.0.1]) by mail.core-networks.de id 1gCQp2-0002Ws-Mf with ESMTPSA (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) for tls@ietf.org; Tue, 16 Oct 2018 16:59:52 +0200 Cc: "" References: <90e2851e-6469-226c-b2bd-63efebdfd796@bartschnet.de> <9700FD81-5DDF-4A14-B740-1216A749510D@dukhovni.org> <652234d7-55da-fea0-e185-6f1264b3fb28@bartschnet.de> From: "Rene 'Renne' Bartsch, B.Sc. Informatics" Message-ID: <5b069d31-4ddc-5905-3458-2a8b365e0c7b@bartschnet.de> Date: Tue, 16 Oct 2018 16:59:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-DE Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] Make DANE-TLS (RFC 6698) mandatory for TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 14:59:56 -0000 I haven't found the article with 150,- $, yet, but this isn't good either: https://www.bankinfosecurity.com/study-finds-custom-market-for-bogus-tls-certificates-a-10680 and Mozilla makes it worse: https://blog.mozilla.org/security/2018/10/10/delaying-further-symantec-tls-certificate-distrust/ Am 16.10.18 um 16:06 schrieb Ted Lemon: > Can you provide a citation for that statement?   Not doubting you, particularly, but this is news to me, and probably to some others on this list, if true. > > On Tue, Oct 16, 2018 at 4:01 PM Rene 'Renne' Bartsch, B.Sc. Informatics > wrote: > > Unjust certificates can be bought for 150,- $ in the darknet which makes TLS snake-oil. And you never know if the internet provider is hostile or hacked. > So we should act in the favor of end-users. If we don't have the position to make DANE mandatory, yet, we should at least try to encourage browser vendors > to support DANE. Just think about all the online-banking websites without DNSSEC/DANE protection. > > > Am 15.10.18 um 22:49 schrieb Viktor Dukhovni: > > Though I am generally an advocate for DANE, and have done much work to > > further its adoption, this is not a realistic proposal.  DANE adoption > > in TLS will be incremental and will not be accomplished via a mandate. > > > >> On Oct 15, 2018, at 4:20 PM, Rene 'Renne' Bartsch, B.Sc. Informatics > wrote: > >> > >> TLS is prone to Man-In-The-Middle attacks with unjustly obtained intermediate certificates (e.g. firewall appliances). > >> The DNSSEC KSK-rollover worked like a charm. > >> > >> So I suggest to make DANE-TLS mandatory for TLS to prevent Man-In-The-Middle attacks with unjustly obtained intermediate certificates. > > > > If you want to see more DANE deployment, work on tooling to ease > > DNSSEC deployment, convince registries to support CDS and CDS0, > > simplify zone signing and key rollover interfaces in nameserver > > implementations, develop monitoring tools, ...  Get efforts to > > improve the tools funded, ... > > > > There is much work to be done, before we can expect ubiquitous > > DNSSEC support, let alone DANE.  DNSSEC deployment is concentrated > > at domains hosted by providers who have invested in automating it. > > To bring it to the masses, it must be something that works out of > > the box. > > > > Until then it should be possible to use DNSSEC and DANE with TLS, > > but we're quite far from being in a position to mandate their use. > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Tue Oct 16 10:28:06 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7BC130DC7 for ; Tue, 16 Oct 2018 10:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMeKe28tktpU for ; Tue, 16 Oct 2018 10:28:02 -0700 (PDT) Received: from mail-it1-f177.google.com (mail-it1-f177.google.com [209.85.166.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0797C130E01 for ; Tue, 16 Oct 2018 10:28:02 -0700 (PDT) Received: by mail-it1-f177.google.com with SMTP id 134-v6so34156409itz.2 for ; Tue, 16 Oct 2018 10:28:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TgKEqplqFjKdK+VfcTyRYFw7Am9jUbekHScbuD0+ql8=; b=nXojmh0jtJoyp9OPH2WnCnrzwVONqCG1Q2slmgSqX4f1QA2GVacUq3r+9eRZ8z6Wff 7gTK8CW/tCKvjEBBvCcplfUgi036ZEoQSceN7E88ZUs2vjOhkf5buVOKCyxiJ0RjuzV3 QhEdKod39XZUcPm11RW5rEapC8gFHpW8T4yk+W3BqPfGzzStFIjYMyOpZ0aaqdxOauYT 8mTOmThXkl9WLhSRSD6X2aLtc3qRmY/Xz2xLOByyOXQOallZxC6Pn/IN9u1Gimim6Zl6 aedfLzpmRWYnqN36eFeFVadgNzXAVj9FA1+VIvdBaOFMxfMUfrlPoaW8axLaojetUaO0 u2Yg== X-Gm-Message-State: ABuFfoh5uVHSLw8O8npl44GJJkLGWbugDQzoJpYLVsKd017Mck9ws3vN byCHHDYUmBqhJ+0GzXhAblUMua6pkLE= X-Google-Smtp-Source: ACcGV61yA9VpAQ62+HJWm8m63nrhF8YCo7mtmMD5thHLJPHqMj8hzqe/DPEWAXyKfEwDzVAVD/rc0A== X-Received: by 2002:a02:b14a:: with SMTP id s10-v6mr18641862jah.38.1539710880745; Tue, 16 Oct 2018 10:28:00 -0700 (PDT) Received: from mail-it1-f179.google.com (mail-it1-f179.google.com. [209.85.166.179]) by smtp.gmail.com with ESMTPSA id u4-v6sm4291016iob.0.2018.10.16.10.28.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Oct 2018 10:28:00 -0700 (PDT) Received: by mail-it1-f179.google.com with SMTP id 134-v6so34156329itz.2 for ; Tue, 16 Oct 2018 10:28:00 -0700 (PDT) X-Received: by 2002:a24:9ed7:: with SMTP id p206-v6mr15678988itd.39.1539710879680; Tue, 16 Oct 2018 10:27:59 -0700 (PDT) MIME-Version: 1.0 References: <90e2851e-6469-226c-b2bd-63efebdfd796@bartschnet.de> <9700FD81-5DDF-4A14-B740-1216A749510D@dukhovni.org> <652234d7-55da-fea0-e185-6f1264b3fb28@bartschnet.de> <5b069d31-4ddc-5905-3458-2a8b365e0c7b@bartschnet.de> In-Reply-To: <5b069d31-4ddc-5905-3458-2a8b365e0c7b@bartschnet.de> From: Ryan Sleevi Date: Tue, 16 Oct 2018 13:27:48 -0400 X-Gmail-Original-Message-ID: Message-ID: To: ietf=40bartschnet.de@dmarc.ietf.org Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000a53dd05785be058" Archived-At: Subject: Re: [TLS] Make DANE-TLS (RFC 6698) mandatory for TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 17:28:04 -0000 --0000000000000a53dd05785be058 Content-Type: text/plain; charset="UTF-8" On Tue, Oct 16, 2018 at 11:00 AM Rene 'Renne' Bartsch, B.Sc. Informatics wrote: > I haven't found the article with 150,- $, yet, but this isn't good either: > > > https://www.bankinfosecurity.com/study-finds-custom-market-for-bogus-tls-certificates-a-10680 > > and Mozilla makes it worse: > > > https://blog.mozilla.org/security/2018/10/10/delaying-further-symantec-tls-certificate-distrust/ I'm afraid that taking that article and extrapolating that it undermines SSL is, unfortunately, a bit unsupported. It's certainly true that "bad actors" are able to misrepresent and circumvent a number of CAs' "Extended Validation" practices. This can range from CAs using unreliable datasources (like Dun & Bradstreet) or to CAs having poor practices regarding acceptable documentation. However, in the examples mentioned in that article (and related, as I recall when that came out), the attack is not that the attacker bypasses the domain name verification process. Instead, the attacker fully controls their own domain name, and they fool the CA into providing additional assertions about that domain name that aren't legitimate - such as what company or entity is operating that domain name. The same applies for EV Code Signing certificates (which aren't bound to domains, but organizations) - by fooling the organization vetting process, systems that rely on the organization information - not the domain name - are the ones put at risk. DANE/DNSSEC would not address that concern, because its largely orthogonal to such extended validation. Indeed, what DANE/DNSSEC would address is exactly the thing that's working and not been compromised - the domain validation part (especially in light of CAA). If your goal is to minimize risk, then I think a key takeaways would be not to rely on organization information in certificates - and instead focus on the domain name. Similarly, rather than promoting DANE/DNSSEC in browsers, you could encourage browsers to adopt solutions like Apple has done in Safari on macOS Mojave - no longer present extended validation UI to users ( https://www.troyhunt.com/extended-validation-certificates-are-dead/ ), so that they can instead reliably use the domain name. --0000000000000a53dd05785be058 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Oct 16, 2018 at 11:00 AM Rene 'Renne' Bartsch, B= .Sc. Informatics <ietf=3D40bartschnet.de@dmarc.ietf.org> wrote:
I haven't found the article with 150,-= $, yet, but this isn't good either:

https:/= /www.bankinfosecurity.com/study-finds-custom-market-for-bogus-tls-certifica= tes-a-10680

and Mozilla makes it worse:

http= s://blog.mozilla.org/security/2018/10/10/delaying-further-symantec-tls-cert= ificate-distrust/

I'm afraid that t= aking that article and extrapolating that it undermines SSL is, unfortunate= ly, a bit unsupported.

It's certainly true tha= t "bad actors" are able to misrepresent and circumvent a number o= f CAs' "Extended Validation" practices. This can range from C= As using unreliable datasources (like Dun & Bradstreet) or to CAs havin= g poor practices regarding acceptable documentation. However, in the exampl= es mentioned in that article (and related, as I recall when that came out),= the attack is not that the attacker bypasses the domain name verification = process. Instead, the attacker fully controls their own domain name, and th= ey fool the CA into providing additional assertions about that domain name = that aren't legitimate - such as what company or entity is operating th= at domain name. The same applies for EV Code Signing certificates (which ar= en't bound to domains, but organizations) - by fooling the organization= vetting process, systems that rely on the organization information - not t= he domain name - are the ones put at risk.

DANE/DN= SSEC would not address that concern, because its largely orthogonal to such= extended validation. Indeed, what DANE/DNSSEC would address is exactly the= thing that's working and not been compromised - the domain validation = part (especially in light of CAA).

If your goal is= to minimize risk, then I think a key takeaways would be not to rely on org= anization information in certificates - and instead focus on the domain nam= e. Similarly, rather than promoting DANE/DNSSEC in browsers, you could enco= urage browsers to adopt solutions like Apple has done in Safari on macOS Mo= jave - no longer present extended validation UI to users (=C2=A0https:= //www.troyhunt.com/extended-validation-certificates-are-dead/ ), so tha= t they can instead reliably use the domain name.
--0000000000000a53dd05785be058-- From nobody Tue Oct 16 13:19:11 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB736130E3D for ; Tue, 16 Oct 2018 13:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkR7u7CxouRD for ; Tue, 16 Oct 2018 13:19:06 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87FB0130E1F for ; Tue, 16 Oct 2018 13:19:06 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id y10-v6so18026845lfj.1 for ; Tue, 16 Oct 2018 13:19:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=i9DZ+xs072mM3gnxVMtQ6mElaFqc0dDRkhV8mrkwwTM=; b=q3Es9pYZTgCyeN76SU3ddnaCPetJUwwv91/u6ExJezFz71tN18svc4T0DELTvZcE2j +8DQWdPV9l04xKLrK0wGGRSMzT3I+QtRBITUuyEJTjeWo3Vtv51SK5XF7iUlZp65K0KI 4Mm1u+EvfsG/3hJG9j0mhlqVr2Z9bN5OiCBup0MBSUXLUQf8uTHjHVfjDLKyTbCfkt4v PyKH/fJAtC5sku9dGxDfJPRBerGu7+/lAyGuyI8GKm6r+u9YMVa1paHImzbHWmkc6raK fXo5d2L0RyglFUL9B4yPB/A0g1dbjILiUNziQPGFojnbPr3LiBTA2XnScSUZ+8QE+gMm vVQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=i9DZ+xs072mM3gnxVMtQ6mElaFqc0dDRkhV8mrkwwTM=; b=NxhakBz6OEziu6NMEbVw4XwoweSTOZ3KxooLJAKAa9rAH7kV1767O4T8IyXfVPosJC bJJAaIU6dLtY1SODKffcg8i/NSiv0Di3gug5scDyD/dnqwy83Uwdfzru8j5gvBbRkQE2 fHs8BEU6VBJXrCk7tkATxBWIk/UUcNtbU4mVsIpcm4U0xfVCGm2lisa2FmBt7ZyTgxYD siT88do0OZ9lWjDlTFn4cVKMTQpnhV8xreoqBHC0pSG+AeP0o1KD2ThEND1nWt4YhOS+ 1FO36f8sh+nw6qEAWxaAQAb6ucinrafOtMMvNPEP/z+5V0umNTwLw254MaCZZcSiiDvw yqHg== X-Gm-Message-State: ABuFfoigWD2uRNtWgmWq9y6cDVhVo9xu3ZajFJwF/68s7EgNm4TkYi/2 W1flA9QNi6HR5fbemTUKsSp/fYaajTCJB/dpwVQ9CgtR X-Google-Smtp-Source: ACcGV60MHoyc6jp5lD05pskxUIQzS81jXE7ykA0BQWwg2QSprRaPodI4Yy5ipwtt3HmVlteoxV0rZ+c6I9G3vOrUxaQ= X-Received: by 2002:a19:5a05:: with SMTP id o5mr2003450lfb.140.1539721144565; Tue, 16 Oct 2018 13:19:04 -0700 (PDT) MIME-Version: 1.0 References: <6bab54cd-e903-ac3e-a186-077458a2d652@simonbernard.eu> In-Reply-To: <6bab54cd-e903-ac3e-a186-077458a2d652@simonbernard.eu> From: Eric Rescorla Date: Tue, 16 Oct 2018 13:18:27 -0700 Message-ID: To: Simon Bernard Cc: "" Content-Type: multipart/alternative; boundary="000000000000e015e405785e4305" Archived-At: Subject: Re: [TLS] HELLO_VERIFY_REQUEST during abbreviated handshake (session resumption) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 20:19:09 -0000 --000000000000e015e405785e4305 Content-Type: text/plain; charset="UTF-8" Hi Simon, I don't think we specified a concrete recommendation, but I think the answer is probably no. The reason is that: (a) a resumed handshake is very cheap, so it's not really saving CPU (b) the server's first flight is small in resumption, so amplification isn't much of an issue. Maybe I'm missing something though. -Ekr On Wed, Oct 3, 2018 at 7:05 AM Simon Bernard wrote: > Hi, > > In DTLS 1.2 over UDP, I would like to know what is the > recommendation about using HELLO_VERIFY_REQUEST during an abbreviated > handshake. > > Should we send it all the time ? or could we avoid to send it if > SESSION ID is known ? > > Thx, > > > Simon > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000e015e405785e4305 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Simon,

I don't think = we specified a concrete recommendation, but I think the answer is probably = no. The reason is that:

(a) a resumed handshake is= very cheap, so it's not really saving CPU
(b) the server'= ;s first flight is small in resumption, so amplification isn't much of = an issue.

Maybe I'm missing something though.<= br>

-Ekr

=C2=A0
=C2=A0

On Wed, Oct 3, 2018 at 7:05 AM Simon Bernard <contact@simonbernard.eu> wrote:
Hi,

=C2=A0=C2=A0=C2=A0 In DTLS 1.2 over UDP, I would like to know what is the <= br> recommendation about using HELLO_VERIFY_REQUEST during an abbreviated
handshake.

=C2=A0=C2=A0=C2=A0 Should we send it all the time ? or could we avoid to se= nd it if
SESSION ID is known ?

Thx,


Simon

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000e015e405785e4305-- From nobody Tue Oct 16 15:06:46 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A73130E51; Tue, 16 Oct 2018 15:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mne8n59p_kIR; Tue, 16 Oct 2018 15:06:36 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B005F130E4B; Tue, 16 Oct 2018 15:06:35 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id q5-v6so27344781wrw.12; Tue, 16 Oct 2018 15:06:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5DRaMZb+8eyiUGToE/O391Y4w1SrgM4c0YW+qgAtK4o=; b=pk4zDpHhP/gaYzg0EzWrosPK/yU53VzdulSgDQYnBe1+ta7d7brEvco/KUFueFhQ5p 7drb1UkW6ZpoK3/iQxvJIE4pf+AVs3mnEdT4j+0toPvj4ywP//PJdGHyZGgithW+I+7n n9jugmyowQ7eVrXoODmGTa6WtrFMV+pVdgjCtNPoZ74/XQtudx01pTHXYANEYr8d847S wZLeQWTVHjE48ial8XoS5v03dl264UvYWIcfRnBPRggpEbdaR3ERnYN1enpqu+I0uoyu y43kUsMdqYHPY+4ofU9ldnraWmKsQRReYl0WqNBP3ioIbeMu4sUejlkxQCGZVrNECd7A ++nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5DRaMZb+8eyiUGToE/O391Y4w1SrgM4c0YW+qgAtK4o=; b=NqbSsGiXv1SH+utixLsn5JuhCiQiuK7ZcyoCdJCrdl4n+uDd7+YzrmfFX9GW2p5Orh yF8YSWntKgBWBdIhMmWrZNgPzwYVYAuJrN6bwcHpTzOZ2F/rwguvW7YcUB05jExrhD8s g542dleeU0XVADHClzAuw+yQYStD+K5EzeXmA6+WTjt5H4IUSyY5KUTkhDDaDz5f75yH sKYBi7R/pG45vqCG0N9ru7HbDWitIcE18Ryd4EpcxIKTF/q9uP9BpLCJfFp3k8ARMeTO t9Jvtr7Yy/axqKuLPzyvrfw/6hY7soNaEY3Sjoj0xnWbi7tnz8YTHmett9E9kEgLe8Zv i8jg== X-Gm-Message-State: ABuFfojgNOojKURO3n74iM+sYM7nnojDn+EwzBqmDzSy/Htd0BGWaX5w ECZ0/63FiuZx8YZpxNQVh+IUDgLxAha5uWHkjojWvCLy X-Google-Smtp-Source: ACcGV63H0JQYk7tO+C/o78XZBcGWHuOBjDeinAoqbsUw2bJp68TD434YeGPjf+AGQ8A8McU1ZDwhM8jYPk1jcCALSpY= X-Received: by 2002:adf:8206:: with SMTP id 6-v6mr20312475wrb.160.1539727593921; Tue, 16 Oct 2018 15:06:33 -0700 (PDT) MIME-Version: 1.0 References: <20181011132641.BC838B804DC@rfc-editor.org> <87va62zapo.fsf@mid.deneb.enyo.de> In-Reply-To: <87va62zapo.fsf@mid.deneb.enyo.de> From: =?UTF-8?Q?Eug=C3=A8ne_Adell?= Date: Wed, 17 Oct 2018 00:06:22 +0200 Message-ID: To: fw@deneb.enyo.de Cc: turners@ieca.com, Tim Polk , iesg@ietf.org, TLS WG Content-Type: multipart/alternative; boundary="00000000000049621705785fc48f" Archived-At: Subject: Re: [TLS] [Errata Rejected] RFC6176 (5520) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 22:06:39 -0000 --00000000000049621705785fc48f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable @Florian The document is about the SSL 2.0 security deficiencies, particularly the ones that brought its prohibition. The solutions to these deficiencies might also have their own problems, as it's often the case in security related topics which look like a never-ending debate (a problem, a solution, a new problem), and they would logically be discussed in their own threads or we would easily make anachronistic comments. The mitigation of a root authority has a huge impact, and requires time to solve, that's what said at that time, although it happened much later to some issuers. In practice we see that direct signed certificates for Internet use were abandoned, without anyone returning back to them. Also, the HSMs are getting more widely used, and it gives more protection to the keying material (which is an answer to the "overexposed keys"). @Ryan Thanks. There's also that link https://www.ietf.org/blog/iesg-processing-rfc-errata-ietf-stream/ which is almost saying the same. But at the same time RFC6176 is not exactly a protocol description, it's a limited update to existing protocols that had warned us this update would be published one day. Submitting an update for a non technical part of this RFC doesn't make much sense too, maybe no more than a rejected errata. Le mar. 16 oct. 2018 =C3=A0 08:12, Florian Weimer a =C3= =A9crit : > * RFC Errata System: > > > Corrected Text > > -------------- > > > o The root certificate authority keys are overexposed. The server > > sends only one certificate signed by a root certificate authority= , > > which means a frequent use of this authority keys for signing new > > certificates. This use can lead to key loss and the compromise of > > all certificates previously signed including the root certificate= . > > > > Notes > > ----- > > Adding a deficiency. > > Recent history showed that well-known authorities could loose their key= s > and it had a wide impact on security. > > SSL 2.0 limits the certificate handshake message to one single > certificate, thus making it impossible to send a certificate chain. > > A certificate chain doesn't completely prevent key loss, but it gives > more protection to the root certificate keys which can be stored and hidd= en > until we need them again, which is much less often than without chaining. > > > > > > > > --VERIFIER NOTES-- > > This isn't an error in the original document. It's new text you want > to add. > > I think it's also historically incorrect. More security problems were > caused by the ability to introduce arbitrary intermediate certificates > by CAs than by too many direct signing operations with a root CA key. > At least for web use, the original model (which does not allow > delegation of trust on the CA side) might actually have been more > approriate. (On the RA side, delegation is of course technically > possible under any model, and it had its share of problems, too.) > --00000000000049621705785fc48f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
@Florian

The document is about the= SSL 2.0 security deficiencies, particularly the ones that brought its proh= ibition. The solutions to these deficiencies might also have their own prob= lems, as it's often the case in security related topics which look like= a never-ending debate (a problem, a solution, a new problem), and they wou= ld logically be discussed in their own threads or we would easily make anac= hronistic comments. The mitigation of a root authority has a huge impact, a= nd requires time to solve, that's what said at that time, although it h= appened much later to some issuers.
In practice we see that direct signe= d certificates for Internet use were abandoned, without anyone returning ba= ck to them. Also, the HSMs are getting more widely used, and it gives more = protection to the keying material (which is an answer to the "overexpo= sed keys").


@Ryan

Thanks. There's also that link= https://www.ietf.org/blog/iesg-processing-rfc-errata-ietf-stream/ w= hich is almost saying the same. But at the same time RFC6176 is not exactly= a protocol description, it's a limited update to existing protocols th= at had warned us this update would be published one day. Submitting an upda= te for a non technical part of this RFC doesn't make much sense too, ma= ybe no more than a rejected errata.

Le=C2=A0mar. 16 oct. 2018 =C3=A0=C2=A008:12, Floria= n Weimer <fw@deneb.enyo.de> a= =C3=A9crit=C2=A0:
* RFC Errata Sys= tem:

> Corrected Text
> --------------

>=C2=A0 =C2=A0 o=C2=A0 The root certificate authority keys are overexpos= ed. The server
>=C2=A0 =C2=A0 =C2=A0 =C2=A0sends only one certificate signed by a root = certificate authority,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0which means a frequent use of this authority= keys for signing new
>=C2=A0 =C2=A0 =C2=A0 =C2=A0certificates. This use can lead to key loss = and the compromise of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0all certificates previously signed including= the root certificate.
>
> Notes
> -----
> Adding a deficiency.
> Recent history showed that well-known authorities could loose their ke= ys and it had a wide impact on security.
> SSL 2.0 limits the certificate handshake message to one single certifi= cate, thus making it impossible to send a certificate chain.
> A certificate chain doesn't completely prevent key loss, but it gi= ves more protection to the root certificate keys which can be stored and hi= dden until we need them again, which is much less often than without chaini= ng.
>
>
>
>=C2=A0 --VERIFIER NOTES--
>=C2=A0 =C2=A0 This isn't an error in the original document. It'= s new text you want to add.

I think it's also historically incorrect.=C2=A0 More security problems = were
caused by the ability to introduce arbitrary intermediate certificates
by CAs than by too many direct signing operations with a root CA key.
At least for web use, the original model (which does not allow
delegation of trust on the CA side) might actually have been more
approriate.=C2=A0 (On the RA side, delegation is of course technically
possible under any model, and it had its share of problems, too.)
--00000000000049621705785fc48f-- From nobody Tue Oct 16 15:16:40 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08CCF130E52 for ; Tue, 16 Oct 2018 15:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zf8K2OYnjBzw for ; Tue, 16 Oct 2018 15:16:37 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4910B130E4B for ; Tue, 16 Oct 2018 15:16:37 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id CAA52F99F for ; Tue, 16 Oct 2018 18:16:35 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id EDE1820356; Tue, 16 Oct 2018 18:16:25 -0400 (EDT) From: Daniel Kahn Gillmor To: tls@ietf.org In-Reply-To: References: Date: Tue, 16 Oct 2018 18:16:22 -0400 Message-ID: <875zy1czbd.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 22:16:39 -0000 --=-=-= Content-Type: text/plain Hi all-- I'm disappointed in how long this WG is taking to get draft-ietf-tls-dnssec-chain-extension out the door. I agree with both Tom and Viktor that the current draft seems to be misaligned between the goals and the stated scope. I wanted the draft to be done by now because i think it will be useful in "greenfield" scenarios -- ones where the use case itself can mandate the extension without negotiation, but i understand Viktor's point that without any sort of negotiated pinning mechanism, the draft is probably not useful for non-greenfield scenarios (without pinning the existence of the extension, it cannot reduce the attack surface represented by the CAs, and instead only represents an additional vector of attack). I can understand why people want to be able to make this useful for non-greenfield scenarios, but it appears that we're hung up on the pinning details. I actually don't think that extension pinning needs to be particularly hard, and i don't think it's as dangerous as HPKP's pinning, but i won't go too far into the weeds here. Just a quick summary of my understanding: * The existence of a pin only requires that the service operator maintain the ability to respond to this extension in the future -- it doesn't require specific keys, or even the use of DANE itself. It is not nearly as large a risk as HPKP's pins were. * Pinning fears are based on two scenarios: (a) footgun, where the service operator makes a mistake, or (b) a malicious pin is set by an adversary who has owned your domain. (a) is overwhelmingly more common, and is what we should focus on. In the (a) scenario, the admin has already deployed the extension, so there is no risk. The (b) scenario only matters if a service cannot deploy the extension as intended, which is more of a chicken/egg problem of deployment and implementation. I don't think that's a huge risk but if we really want to try to cover it, i think there are ways that we could minimize it as well. That said, it sounds like negotiating the details of how to do this pinning is the main blocker, and i'm sick of this proposal being blocked (because i want it for "greenfield" implementations last year). So one way forward would be to complete this extension without the pinning (explicitly acknowledging that it will not be useful for non-greenfield implementations on its own) and get it out the door. Then we can subsequently create a new extension that is only a "how-to-pin-dnssec-chain-extension". This is an approach that would expose at the protocol layer the ugly truth about how hard it is to get something through the IETF process, but if it helps to break the impasse, i'd be all for it. I'm willing to provide text for why this is only useful for greenfield implementations, if asked. Alternately, if people could agree on a simple and clear pinning scheme that we could get out the door all in one piece, i'd be happy with that too. I will be sad if we manage to not get anything at all completed for another year. --dkg, tired of waiting --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTTaP514aqS9uSbmdJsHx7ezFD6UwUCW8ZjNgAKCRBsHx7ezFD6 U5rsAP9KAgQes1Y1/9Sq3BOxfs4S2LwnbmQiaN9OYCHMatGOYAD/aeyNljh0ym3m d59Q/QcP5gYpTLb7ZNboBPQXZ7lA/wQ= =A/lX -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Oct 16 15:43:10 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B3C130E52 for ; Tue, 16 Oct 2018 15:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnrUxR4NcE7x for ; Tue, 16 Oct 2018 15:43:08 -0700 (PDT) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F06AA130E37 for ; Tue, 16 Oct 2018 15:43:07 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id 12-v6so15258961qkj.10 for ; Tue, 16 Oct 2018 15:43:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=5R8gOlYpZTMB2H36uBrSDPDOHEWygOVjdgFT+l68/5Q=; b=I6JEgh2dzoaH8RhexMTuHTOWKTXyPzW9XHodz4pCU6R4R6FDLXuByDCKQTXOnWkjUh LuxYA2xStrG/W57u+JKeTEnKhqQGePD6WdAYQe3i+8In4TJhlfBshLyCRy/j8JrbGqCE ylKLa+Xe374lsFhyd1e7UlZ/RtzlBPVfZQObk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=5R8gOlYpZTMB2H36uBrSDPDOHEWygOVjdgFT+l68/5Q=; b=XEYcDaOhtf98oHVinza5imItckyQgoW+rOXYNwJZspvymPNOg5amAmmoD5ABH+DRTQ 0iHgGkTUaG3lbVqxXFNJNMXYaeRoeBXRZL6T028NcNB4xjhuugznyMjg+v6zmLxZuf1t ffkH/zoug0GNm8WbmwsOjDLIh6XgIoZhyWM3muSUw5RJYIov3Gv9de/D+KzXQp4Td6wC SADeeLIo8kX6/mjZGtDUSxwMFrLNMsgoYqIGIEjnmU62+EzuS9h8rwXAmzsbg+cpa8VG rSVUgPut0W6FNh4145e8x0LYPcvoPwUXGX2eh7ujc0AMuo0yrCGNzCjBfBmPkPhTx8NX STBw== X-Gm-Message-State: ABuFfojyrBeAX5sV+c8jbnseNyDqFEYJvmiCO5bderSx2SK5Lh3SWdsy iDRE/2hZf0zpI6MRtThI8ngDDX19mDA= X-Google-Smtp-Source: ACcGV604hcUQxn2uq9hmtIcB0PfJwDaZniqGIKnFtwGmBR/0pTWyLHRxLS+Dh3eouRk8CHgeyUXoqg== X-Received: by 2002:a37:ef08:: with SMTP id j8-v6mr23089893qkk.26.1539729787011; Tue, 16 Oct 2018 15:43:07 -0700 (PDT) Received: from [172.16.0.18] ([96.231.224.191]) by smtp.gmail.com with ESMTPSA id f85-v6sm12155222qkh.35.2018.10.16.15.43.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Oct 2018 15:43:06 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <9DE64F7F-4740-4410-A004-373D8919920B@sn3rd.com> Date: Tue, 16 Oct 2018 18:43:05 -0400 To: tls@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [TLS] WGLC for draft-ietf-tls-sni-encryption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 22:43:10 -0000 All, This is the working group last call for the "Issues and Requirements for = SNI Encryption in TLS" draft available at = http://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/. Please = review the document and send your comments to the list by 2359 UTC on 31 = October 2018. Thanks your chairs: C-J-S= From nobody Tue Oct 16 16:03:50 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45B13130E5F for ; Tue, 16 Oct 2018 16:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efex4GLdfEJY for ; Tue, 16 Oct 2018 16:03:45 -0700 (PDT) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87B82130E5D for ; Tue, 16 Oct 2018 16:03:45 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id 23-v6so15273419qkh.8 for ; Tue, 16 Oct 2018 16:03:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=OK1iH4SIJlQn6zgBdww0zMzIF6tfRkku0CQDfTu6Hu8=; b=WpsOE4Ze8oyubOptT6v9jqTNsE4p2QIh9vTOTDOa4hnLkGzV+f84GHkc+EjCwgMPUw 2vCub1Owmn/7UzsiJ1lqf3oK4tGZ5KHqhyy3Mb1lieQXdTtR+J6teHdI6lDIJe+vFcaT ibUqO2+2/caz9E2hn+3zQmrZrGGFXU5NP6ApI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=OK1iH4SIJlQn6zgBdww0zMzIF6tfRkku0CQDfTu6Hu8=; b=LDzwMmlycW12KIRNJ8AlLEnxmTKicRqEyuSbDz+iYnclTEAvSyOdQ4Z0PKkUGhn+2V zRtqdaBO79w0gW44JTdXuhRuDw+3XMzvGQLu0mdQLB9E6Ivr5CU2gSQHuVIBTn1ipLZ5 92kKlXcUyKfdr/turmMg+S9dxGIMkC1v71JICLuwyMF7i7LleK1x+7nmNS9TpWiM031e +52IkJIyYDcAmep2LyNsvUaLtAuxJKP9HEe4u/QHw+ejzJKOCLwDF/8CjTimLIvWeft+ dGy0m95v54hbjDxphQkcPM694LflXLl8/vTW7YbAYOZq0PldcsXFu+YULiETZDf+h9Cc eAxQ== X-Gm-Message-State: ABuFfoghlCLgY1Zj+hpyb0E3570wjbeZQpSJreAEk7tXvLLtlc4oiIcP VTYysVmmdZnU0Ljq0BFkGRl0ZQpC9Q8= X-Google-Smtp-Source: ACcGV63UlZfAmuZPbTyRCl2nx7+X2ZNgOudfsM3Uq+gVUkgZs9AkDxu4x9Iz7djTjMMTy8wWn+SQ2Q== X-Received: by 2002:a37:1610:: with SMTP id g16-v6mr613422qkh.336.1539731024574; Tue, 16 Oct 2018 16:03:44 -0700 (PDT) Received: from [172.16.0.18] ([96.231.224.191]) by smtp.gmail.com with ESMTPSA id u18-v6sm13073442qtb.63.2018.10.16.16.03.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Oct 2018 16:03:43 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 16 Oct 2018 19:03:42 -0400 References: <9DE64F7F-4740-4410-A004-373D8919920B@sn3rd.com> To: tls@ietf.org In-Reply-To: <9DE64F7F-4740-4410-A004-373D8919920B@sn3rd.com> Message-Id: <9F1B6F5B-D6A4-4A83-8424-E07FA4D81616@sn3rd.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-sni-encryption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 23:03:47 -0000 All, I ran I-D nits before hitting the appropriate buttons to place this = draft in WGLC. I figured we could address the following before we send = the draft to Ben: =3D=3D Outdated reference: draft-ietf-tls-tls13 has been published as RFC 8446 =3D=3D Outdated reference: A later version (-14) exists of draft-ietf-doh-dns-over-https-08 =3D=3D Outdated reference: A later version (-15) exists of draft-ietf-quic-tls-11 =3D=3D Outdated reference: A later version (-28) exists of draft-ietf-tls-dtls13-26 =3D=3D Outdated reference: draft-mm-wg-effect-encrypt has been published as RFC 8404 To answer the other 5 I-D nits questions "Obsolete informational = reference (is this intentional?)=E2=80=9D - the answer is yes. spt > On Oct 16, 2018, at 18:43, Sean Turner wrote: >=20 > All, >=20 > This is the working group last call for the "Issues and Requirements = for SNI Encryption in TLS" draft available at = http://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/. Please = review the document and send your comments to the list by 2359 UTC on 31 = October 2018. >=20 > Thanks your chairs: C-J-S From nobody Tue Oct 16 16:29:27 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21AF5130E37 for ; Tue, 16 Oct 2018 16:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzpE3oxOaqtb for ; Tue, 16 Oct 2018 16:29:22 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCE3D130E5D for ; Tue, 16 Oct 2018 16:29:22 -0700 (PDT) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id DCA742C069 for ; Tue, 16 Oct 2018 19:29:20 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Viktor Dukhovni In-Reply-To: <875zy1czbd.fsf@fifthhorseman.net> Date: Tue, 16 Oct 2018 19:29:19 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: "" Message-Id: <1D203A59-C1FA-4F3F-A9F9-43E2E58C075E@dukhovni.org> References: <875zy1czbd.fsf@fifthhorseman.net> To: "" X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 23:29:25 -0000 > On Oct 16, 2018, at 6:16 PM, Daniel Kahn Gillmor = wrote: >=20 > Just a quick summary of my understanding: >=20 > * The existence of a pin only requires that the service operator > maintain the ability to respond to this extension in the future -- = it > doesn't require specific keys, or even the use of DANE itself. It = is > not nearly as large a risk as HPKP's pins were. >=20 > * Pinning fears are based on two scenarios: (a) footgun, where the > service operator makes a mistake, or (b) a malicious pin is set by = an > adversary who has owned your domain. (a) is overwhelmingly more > common, and is what we should focus on. In the (a) scenario, the > admin has already deployed the extension, so there is no risk. The > (b) scenario only matters if a service cannot deploy the extension = as > intended, which is more of a chicken/egg problem of deployment and > implementation. I don't think that's a huge risk but if we really > want to try to cover it, i think there are ways that we could > minimize it as well. Thanks, that summary looks quite accurate. > That said, it sounds like negotiating the details of how to do this > pinning is the main blocker, and i'm sick of this proposal being = blocked > (because i want it for "greenfield" implementations last year). To be fair, the present delays date back to just March/April. Until that time the draft was blocking waiting for TLS 1.3 to be finished first. So it has only been a few months. > So one way forward would be to complete this extension without the > pinning (explicitly acknowledging that it will not be useful for > non-greenfield implementations on its own) and get it out the door. > Then we can subsequently create a new extension that is only a > "how-to-pin-dnssec-chain-extension". At this point, I think that would be a mistake. The draft still needs much work. Though pinning has been a blocker, it has many other smaller defects that have to be addressed, now that it is back for revision. The draft fails to specify correct semantics for SNI, and leaves out the port number from the client extension, but it is needed. The draft fails to explain the server's responsibility to decrement RRset TTLs if the server is providing previous cached data. The draft fails to describe how virtual hosting should be handled. The RRset ordering is unnecessary, and complicates the exposition. Bottom line, there isn't a document that can (or at least should) land back in the IESG queue with minimal changes. It needs a bunch of changes, and so we should really also resolve the pinning issue, it is NOT that difficult. It has been a series of misperceptions all along. > Alternately, if people could agree on a simple and clear pinning = scheme > that we could get out the door all in one piece, i'd be happy with = that > too. The proposed extension lifetime field is all it takes, there is no feasibility or need for a testing mode (because there's no way to authenticate such a mode, or else we again lose downgrade protection, and the analogy with HTTP STS is imperfect, and does not carry over). There's also no need for "reporting URIs", failure signaling is much better done in-band, via a suitable TLS alert. All that's left to iron out is the maximum duration for the pin lifetime, and whether we need to gradually scale it up as a function of RFC lifetime, giving sites more protection from hijack DoS (if that's really considered important enough to complicate the design). --=20 Viktor. From nobody Tue Oct 16 16:59:24 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12FFB130E9A for ; Tue, 16 Oct 2018 16:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Caiy_oRR9WDu for ; Tue, 16 Oct 2018 16:59:11 -0700 (PDT) Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DE73130E70 for ; Tue, 16 Oct 2018 16:59:11 -0700 (PDT) Received: by mail-oi1-x230.google.com with SMTP id j68-v6so19626323oib.7 for ; Tue, 16 Oct 2018 16:59:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=fGyfEjlqsMS8euqvOUbKkxjpIOZjwnMQHan0C7KdXOE=; b=DtdZzyC5NCr0vt/3q6z1F6lfv151z9RxXA7FAWM2hTwBT+W5TDAgcQvQ9DAq0kzLI1 c/GTgLNJf9q4wBEdAJZtSxfOrHp0ahYaN0rkVxD4wUtQZJB/yScgt/6MDItLGSOLbWmZ jSl8wCH99pdKMRjvze0r65R8uxqwfgGd8nhdo2Yh+2E8BGupwc54jbsR1g9Cej7sUb6c A345c+MrmzNAU1KfrhumL4ahxJbB0iQL/P6YecLo2TZqchcQnyVMZL62t/psqS1bxdCy rRGlBMJSonvXrfnt096dtOFf92ogSMZAa1DJr487nXokKx35bebwEEahi857ZrUA0Sp4 SHMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=fGyfEjlqsMS8euqvOUbKkxjpIOZjwnMQHan0C7KdXOE=; b=F6Kl4qorNt9Uzct5cFZ1HvDBj2c/7lkpAripNwcOxdzb9L3608HvGuQL0OOFCZ9j30 q0eKdtBAIYCzS17WJybimAPf0wA7nc7ttUiMoDp4Onk/oP1pm/xO42fAhmvgQ/jMsXem QyeicnvJhXGTBr/WNu8dJWL29JyGyA/RT61yM1EYTS0dJnZLOw8tJYqHBxXYbxKAQzKL jW6N33Hf4bMd5ELf0yTVekzRKSudiiYsv1+0IBV//g+9dCosHCcGQiqqPbS1HXUTG8Qu wYpwLYHf8P2uj4XslNR+baQJ2aJMWC0pLYD37JAZmu9GjbJwYphfU7xeTYroYxHnU5Oc eTug== X-Gm-Message-State: ABuFfogSwx5CyIp9C9kpPRfvUHkSjO1QYr/Nfw6R8CJ9IO2ABuP3ZsgV SQsb7DWGCagvUOTcOuIbMlfS7NSNATz3ptU1p3IXIm8FNTM= X-Google-Smtp-Source: ACcGV600/5/XtIDmB1eJ+su08EvI0Oe6mvgLkMLV1ymcH35BAl3KrhTwGbTBSn824AcFYDeWecn/UsLTEBgQqMHASjU= X-Received: by 2002:aca:de46:: with SMTP id v67-v6mr13380326oig.167.1539734350322; Tue, 16 Oct 2018 16:59:10 -0700 (PDT) MIME-Version: 1.0 References: <9DE64F7F-4740-4410-A004-373D8919920B@sn3rd.com> <9F1B6F5B-D6A4-4A83-8424-E07FA4D81616@sn3rd.com> In-Reply-To: <9F1B6F5B-D6A4-4A83-8424-E07FA4D81616@sn3rd.com> From: Martin Thomson Date: Wed, 17 Oct 2018 10:58:58 +1100 Message-ID: To: Sean Turner Cc: "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-sni-encryption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 23:59:22 -0000 This is a pretty good piece of information that is very nearly done. Regarding the idnits results, DoH is done, but DTLS and QUIC are still a way off. Would we prefer publication with downref or waiting? For me, this depends somewhat on the maturity of the documents that depend on this. I'd be willing to wait until those documents would have to wait for this one. 3.6 mentions attack by the fronting server or the multiplexed server. But the multiplexed server is the desired endpoint. I think that you can drop any reference to the multiplexed server here. It might require some reframing. 3.8.1 says that it "is thus desirable that SNI Encryption mechanisms be also able hide the ALPN." I think that we ultimately decided that while the techniques might be usable, it would be preferable to encrypt these independently. (Noting that SNI encryption as specified is rather bulky...) 3.9 suggests that parameters might be stripped from the ClientHello: When designing SNI encryption schemes, we have to take into account attacks that strip parameters from the Client Hello, or replay attacks. In both cases, the desired behavior is to fall back to a connection with the fronting server, so there is no visble difference between a regular connection to that server and an attempt to reach the hidden server. But any attack that modifies the ClientHello will cause the handshake to fail when the client receives the Finished from the server (i.e., immediately). Not to mention the server certificate being for a name the client doesn't expect. The problem is that you can construct scenarios with controlled release of a spoofed server flight to test whether a client is willing to continue the connection. Note that you can't do a controlled release of a real flight from a server because any modification to the ClientHello will result in different handshake keys. (Note also the typo: visble) I don't know what was really intended by this section, but it needs work. 4 fails to acknowledge other work in this area, like draft-ietf-httpbis-http2-secondary-certs and the ORIGIN frame (RFC 8336). Nits: The document contains a mix of title- and sentence- case headings. Terms are inconsistently capitalized throughout (like Fronting Server). 2.1 list construction requires "and" or "or" o Enterprise firewalls blocking web sites not deemed appropriate for work, +and+ 2.3 missing "of" Deploying SNI encryption will help thwarting most +of+ the "unanticipate= d" 3.8 subject object disagreement The SNI encryption requirement do+es+ not stop with HTTP over TLS. 3.9. Fail to fronting <- not sure what this phrase means 3.9 also has inconsistent use of "client hello" vs. "Client Hello". I think that it's supposed to be "ClientHello". 4 just drop "/some-content" from the example, it doesn't help (and it's badly wrapped) 4 mismatched quotes on 'co-tenant" On Wed, Oct 17, 2018 at 10:04 AM Sean Turner wrote: > > All, > > I ran I-D nits before hitting the appropriate buttons to place this draft= in WGLC. I figured we could address the following before we send the draf= t to Ben: > > =3D=3D Outdated reference: draft-ietf-tls-tls13 has been > published as RFC 8446 > > =3D=3D Outdated reference: A later version (-14) exists of > draft-ietf-doh-dns-over-https-08 > > =3D=3D Outdated reference: A later version (-15) exists of > draft-ietf-quic-tls-11 > > =3D=3D Outdated reference: A later version (-28) exists of > draft-ietf-tls-dtls13-26 > > =3D=3D Outdated reference: draft-mm-wg-effect-encrypt has > been published as RFC 8404 > > To answer the other 5 I-D nits questions "Obsolete informational referenc= e (is this intentional?)=E2=80=9D - the answer is yes. > > spt > > > On Oct 16, 2018, at 18:43, Sean Turner wrote: > > > > All, > > > > This is the working group last call for the "Issues and Requirements fo= r SNI Encryption in TLS" draft available at http://datatracker.ietf.org/doc= /draft-ietf-tls-sni-encryption/. Please review the document and send your = comments to the list by 2359 UTC on 31 October 2018. > > > > Thanks your chairs: C-J-S > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Oct 16 18:07:29 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 536D6130E6D for ; Tue, 16 Oct 2018 18:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=hfCk+MQW; dkim=pass (1536-bit key) header.d=taugh.com header.b=IJsaimnv Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbXFjT_c6-oq for ; Tue, 16 Oct 2018 18:07:22 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39242130DC5 for ; Tue, 16 Oct 2018 18:07:22 -0700 (PDT) Received: (qmail 9117 invoked from network); 17 Oct 2018 01:07:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=2396.5bc68b48.k1810; bh=tzVaOMQ1SPuYEnQa+Z56wrEq/+ScXKSFrx1IiV62JKQ=; b=hfCk+MQWRY/T+vqng3WjK/FLr917v6pqRzvC3d6fcQDykpL8cu8rv1KiH9QInXfbSNat+kdgTvMyVWOXAcTEYNtmaYsi6NDHCaCurQtS4XHGeTllNnD+6m8W3DP5uwAs81YJHhQXfull5ECr8O87oxx224mRgF21PY7Mwdg166migfcD/CTQNeYwAsEbugzt74kkCie6DzleMGeaK5INpomBsarF4xSxSKpRa7vcaeBEEgAMWyYk4CB7Osnz2sAi DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=2396.5bc68b48.k1810; bh=tzVaOMQ1SPuYEnQa+Z56wrEq/+ScXKSFrx1IiV62JKQ=; b=IJsaimnvFt6qANWlntcpuAY4LSRQTwCWA32/kWGzDCcb9J5mvjlTpbunn1s3dN1adHBDptzYi/kCdQhbb0NbRogJA0TW9Bbz+/B/r5S3BHFFhbOxcT4cKXF/O9VNs18Af0wVyMNnbrR/U1TTth+v6PzOEE8SZz2XW218xILp2+TxV0nl3zd7rp/fYE6mU76LJGIoQNUer0/X39BB+C+9qWRXJJP6iZPUk48zhKAZjTA5hxC/HNRMGh/cnuj7MsnV Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 17 Oct 2018 01:07:20 -0000 Received: by ary.qy (Postfix, from userid 501) id 3C81D2006F8412; Tue, 16 Oct 2018 21:07:19 -0400 (EDT) Date: 16 Oct 2018 21:07:19 -0400 Message-Id: <20181017010720.3C81D2006F8412@ary.qy> From: "John Levine" To: tls@ietf.org In-Reply-To: <875zy1czbd.fsf@fifthhorseman.net> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 01:07:24 -0000 Hi from DNS land. >pinning, but i won't go too far into the weeds here. Just a quick >summary of my understanding: > > * The existence of a pin only requires that the service operator > maintain the ability to respond to this extension in the future -- it > doesn't require specific keys, or even the use of DANE itself. It is > not nearly as large a risk as HPKP's pins were. > > * Pinning fears are based on two scenarios: (a) footgun, where the > service operator makes a mistake, or (b) a malicious pin is set by an > adversary who has owned your domain. (a) is overwhelmingly more > common, and is what we should focus on. In the (a) scenario, the > admin has already deployed the extension, so there is no risk. The > (b) scenario only matters if a service cannot deploy the extension as > intended, which is more of a chicken/egg problem of deployment and > implementation. I don't think that's a huge risk but if we really > want to try to cover it, i think there are ways that we could > minimize it as well. Something like "require DANE certs until time N" should be plenty. Remember that you can also unpin by publishing a signed NXDOMAIN or NODATA. Since you need to have DNSSEC working to get the pin in the first place, that doesn't seem unduly onerous. If your system goes totally kerflooie and your DNS was signed yesterday and for some reason you can't sign it today, you have a problem, but that doesn't sound like a very likely problem. It it does happen, it's as likely as not an attack in which case you'd want attempts to unpin to fail. R's, John From nobody Tue Oct 16 18:15:22 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5616B1252B7 for ; Tue, 16 Oct 2018 18:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.766 X-Spam-Level: X-Spam-Status: No, score=-0.766 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFtpfNbk76uP for ; Tue, 16 Oct 2018 18:15:19 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A15F126CC7 for ; Tue, 16 Oct 2018 18:15:19 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.23/8.16.0.23) with SMTP id w9H17PTm027427; Wed, 17 Oct 2018 02:15:17 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=BBpQL/cYGTgdbHt1RyYmSXiM0mj3O6AjiGK9JtWgHps=; b=a/jKU9fpsSpzhCAQgK46xgaIO14V8aOpvI2eXISmjoc+pHB642uWh2LaXdyXBl4HKt+Z 5ul7UGywHML0XwIsP+JVpgdEjnM0kUgMTrf98rqw1lPipLxDdUTvDvGNSKponjuQrYH1 +nR4J/z/Zt3CpgB0gDVB7Tp8ggRgxKI4N6yTyBNE3n2aCXPWCdpnAw0fa7w7nq8eDvIV M9/sIWZuJBt1t3YStpCSzfxV/KYpicAFpd+DgbL55gwBN3gnN4C01Yd+9hr1uW2rpta/ Hl826/OEKmSzbfXPRsGRFfeInNQoNxCjlhgVEpCA6eYg+tBm1RiYGmOW0BRRQ40M7YL7 9g== Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2n5neagxs9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 17 Oct 2018 02:15:17 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w9H15IeH017414; Tue, 16 Oct 2018 21:15:16 -0400 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint4.akamai.com with ESMTP id 2n3c2cyxjg-1; Tue, 16 Oct 2018 21:15:16 -0400 Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 3F32720069; Wed, 17 Oct 2018 01:15:16 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1gCaQd-0002UC-GW; Tue, 16 Oct 2018 20:15:15 -0500 Date: Tue, 16 Oct 2018 20:15:15 -0500 From: Benjamin Kaduk To: Daniel Kahn Gillmor Cc: tls@ietf.org Message-ID: <20181017011515.GL7773@akamai.com> References: <875zy1czbd.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <875zy1czbd.fsf@fifthhorseman.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-16_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810170007 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-16_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810170008 Archived-At: Subject: Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 01:15:21 -0000 On Tue, Oct 16, 2018 at 06:16:22PM -0400, Daniel Kahn Gillmor wrote: > > I agree with both Tom and Viktor that the current draft seems to be > misaligned between the goals and the stated scope. I also agree that there is some misalignment of this nature. My attempt at a root cause analysis would be that the current text in the Introduction is essentially saying "let clients in bad networks do DANE", but "doing DANE" is a fairly nebulous thing, and if different people are focusing on "doing DANE" in different ways, we can get into conflict about whether a specific proposed mechanism advances our particular goals. So what is "doing DANE", then? In the course of the on-list, off-list, side meeting and interim discussions, I've benefited greatly from hearing from a lot of experts, and I deeply appreciate the patience and persistence that the participants thereof have shown in working to advance a document in this space. It was not always easy, but I think we are making progress. In the context of this discussion, I propose that DANE is a way to allow a TLS server operator[1] to indicate to a TLS client information about how the server would like to be authenticated. The practical effect of this new source of information depends on what the client would be doing *without* the DANE information, though, since we have this large deployed base that is currently not doing DANE but could do DANE in the future. If we want to analyze the (security and other) properties of adding DANE, we must consider both the starting point and the end state. I suggest that if we limit the stated scope from an open-ended "doing DANE" to also state which cases of "doing DANE" we have analyzed (leaving open the possibility for future analysis to confirm the mechanisms we define as usable in other cases), then we can get a clear answer on whether the proposed mechanism meets the requirements of each listed case, without introducing negative externalities for either the protocol participants or the Internet as a whole. This is not to exclude the "greenfield" case, of course -- a list of cases to consider might include things like: - client does not currently exist, and insists on receiving DANE records via TLS extension; server wants to use TLSA with PKIX-{TA,EE} - client does not currently exist, and insists on receiving DANE records via TLS extension; server wants to use TLSA with DANE-{TA,EE} - client currently accepts "Web PKI" certificates but is willing to do DANE; server wants to use TLSA with PKIX-{TA,EE} - client currently accepts "Web PKI" certificates but is willing to do DANE; server wants to use TLSA with DANE-{TA,EE} - client currently will opportunistically accept any certificate but is willing to apply DANE restrictions; server wants to use TLSA with DANE-{TA,EE} - client currently will opportunistically accept any certificate but is willing to apply DANE restrictions; server wants to use TLSA with PKIX-{TA,EE} where I separate out the DANE- and PKIX- usage values since they may require a separate security analysis. (If they don't; great, we can consolidate them in the document.) I don't think we would necessarily need to come to consensus on which of these cases are "most important", so long as we can provide a mechanism that will satisfy the requirements of all cases that we want to list in the document. > I wanted the draft to be done by now because i think it will be useful > in "greenfield" scenarios -- ones where the use case itself can mandate > the extension without negotiation, but i understand Viktor's point that > without any sort of negotiated pinning mechanism, the draft is probably > not useful for non-greenfield scenarios (without pinning the existence > of the extension, it cannot reduce the attack surface represented by the > CAs, and instead only represents an additional vector of attack). Right -- if the client is currently willing to do Web PKI (or worse), an attacker that can get a bogus Web PKI (or self-signed) certificate could keep the client ignorant of the true server's preference and get the client to errenously complete a handshake. We would like a way to deprive the attacker of such a capability, though in at least some situations we cannot do so with 100% reliability. We could perhaps have a success criteria for this TLS extension (as a security mechanism), that it both: (1) provides a channel for DANE records that is reliable in the absence of an attack and (2) reduces the ability of an attacker to cause the client to ignore the server's authentication preference I think that just meeting the above two conditions could provide enough value to merit publishing, even without attempting to add something like: (3) allows the client to realistically hard-fail connections where DNSSEC validation returns bogus or indeterminate. Getting (1) is probably trivial (though with middleboxes you never know), and it seems fairly clear that a pinning scheme can provide (2). (3) is more subjective and may be hard for us to make any definitive statements about, hence my proposal to exclude it for now. -Ben [1] I feel comfortable consolidating the TLS server operator with the maintainer of the DNS entr(y|ies) for that server, since the TLSA entries must reflect the operational reality of the TLS server, and if the two entities are in conflict either can trivially cause an outage. From nobody Tue Oct 16 18:24:11 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340A8130E63 for ; Tue, 16 Oct 2018 18:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQR9tYQLCNw7 for ; Tue, 16 Oct 2018 18:24:06 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F8951271FF for ; Tue, 16 Oct 2018 18:24:06 -0700 (PDT) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 684992C21B for ; Tue, 16 Oct 2018 21:24:05 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Viktor Dukhovni In-Reply-To: <20181017010720.3C81D2006F8412@ary.qy> Date: Tue, 16 Oct 2018 21:24:04 -0400 Content-Transfer-Encoding: 7bit Reply-To: "" Message-Id: <7EB925F0-0010-42B5-8B6D-5D03864231C4@dukhovni.org> References: <20181017010720.3C81D2006F8412@ary.qy> To: "" X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 01:24:08 -0000 > On Oct 16, 2018, at 9:07 PM, John Levine wrote: > > Something like "require DANE certs until time N" should be plenty. > > Remember that you can also unpin by publishing a signed NXDOMAIN or > NODATA. Since you need to have DNSSEC working to get the pin in the > first place, that doesn't seem unduly onerous. To be clear the "require DANE certs" above only holds so long as the TLSA records remain published. Since providing proof of non-existence clears the pin, what's really pinned is the extension (and even then, many clients will be able to recover by making independent DNS lookups). So there's no discord here between "require DANE certs" and "just pin the extension", the two are equivalent, because the former really means "require the extension and if signed TLSA records are present require DANE, else, with valid denial of existence, clear the pin". So regardless of how we frame it, the behaviour after first contact is the same, that is: * Apply DANE in a downgrade-resistant manner when published * Drop pins and revert to default behaviour given valid denial of existence. So far, no substantive issues have been noted with the proposed pinning approach to downgrade resistance (which bears no resemblance to HPKP). All that remains is agreement on a maximum time limit (by setting the time unit to max_time/2^16), and perhaps some sort of gradual scaling up of that limit (if concerns about hijacking before the extension is widely available in server software are deemed sufficiently compelling). -- Viktor. From nobody Tue Oct 16 22:46:31 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02FDC130DC5 for ; Tue, 16 Oct 2018 22:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bj4bNq_SzK40 for ; Tue, 16 Oct 2018 22:46:29 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D70181294D0 for ; Tue, 16 Oct 2018 22:46:28 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 42Zh4d2t7Pz1rV; Wed, 17 Oct 2018 07:46:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1539755185; bh=75E4ufQq2U4q6f1Kc0KS8vDn3CZKQ2ERyXdUV0RM7fA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=JIUw+AscqDrA5rn9kUq6UUapQQOJ09FeXY50RwbnGzCYJsHLqeg+Z2b1yCxuCICme Eruguw1gXwtrmJMOX+Rfq/J15yUQKjbphwx5XFE+xJci+DUhSSTVa6u+2VwxKtGMVh Aa3i9+yWa0xGJNExEC1yybPyfDGTxPTmOoDKOVDM= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Pytsn99lDCKA; Wed, 17 Oct 2018 07:46:22 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 17 Oct 2018 07:46:21 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 0D4F42C40EB; Wed, 17 Oct 2018 01:46:21 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 0D4F42C40EB Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0136141C3B33; Wed, 17 Oct 2018 01:46:20 -0400 (EDT) Date: Wed, 17 Oct 2018 01:46:20 -0400 (EDT) From: Paul Wouters To: Daniel Kahn Gillmor cc: tls@ietf.org In-Reply-To: <875zy1czbd.fsf@fifthhorseman.net> Message-ID: References: <875zy1czbd.fsf@fifthhorseman.net> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 05:46:31 -0000 On Tue, 16 Oct 2018, Daniel Kahn Gillmor wrote: > That said, it sounds like negotiating the details of how to do this > pinning is the main blocker, and i'm sick of this proposal being blocked > (because i want it for "greenfield" implementations last year). Imagine how sick I will be when I try to do this later in a separate docment, where the WG might not even accept it as a WG item. I am not confident enough that pinning would be resolved in a later document at all, leaving me with my use case dead in the water forever. So for me it is useful to have the pressure of release for those people who have a greenfield application to want this to happen to push for resolving the downgrade attack. It forces the parties to the table to resolve the conflict. But also, we already had a suggestion on how to postpone the pinning solution to another document, but to do that sanely this document needed some placeholder or else you end up with a pinning extension that pins itself _and_ another extension, or a placeholder for the meaning of a pin, and both situations were deemed worse then just working out everything in one document. So in effect we already tried what you are proposing. Finally, as Viktor said, our discussions offlist an onlist, found other issues. While Viktor and I are happy to write text to fix these other issues in the document, it seems we are currently stuck in a role of spending a lot of effort writing text, only to see no new draft version on even the things everyone agrees on, such as denial of existence. Since Viktor and I put in a lot of effort to write text that isn't being accepted or rejected, we don't feel very motivated to fix all these other things we found. In my opinion, this document needs more active authors proposing and writing text. It seems none of the original authors is willing or able to do this anymore. If nothing has changed at the next IETF, I have planned to propose adding one or two new authors to the document to try and get it unstuck. I also want to note that Ben has done a very admirable job of talking to everyone and moving towards consensus. Paul From nobody Tue Oct 16 23:39:01 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3FA130E74 for ; Tue, 16 Oct 2018 23:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSBNatDlZTpp for ; Tue, 16 Oct 2018 23:38:56 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EA3412F1A5 for ; Tue, 16 Oct 2018 23:38:56 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 6CE902C5AD; Wed, 17 Oct 2018 02:38:54 -0400 (EDT) Date: Wed, 17 Oct 2018 02:38:54 -0400 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20181017063854.GG983@straasha.imrryr.org> Reply-To: tls@ietf.org References: <875zy1czbd.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 06:38:58 -0000 On Wed, Oct 17, 2018 at 01:46:20AM -0400, Paul Wouters wrote: > On Tue, 16 Oct 2018, Daniel Kahn Gillmor wrote: > > > That said, it sounds like negotiating the details of how to do this > > pinning is the main blocker, and i'm sick of this proposal being blocked > > (because i want it for "greenfield" implementations last year). > > Imagine how sick I will be when I try to do this later in a separate > docment, where the WG might not even accept it as a WG item. I am not > confident enough that pinning would be resolved in a later document at > all, leaving me with my use case dead in the water forever. Agreed, but at the same time in DKG's response, beyond the frustration with the process, I see real signs of potential progress in the form of broad agreement with the points we'ev made about the need for and the nature of the proposed pinning approach. So frankly, barring strong evidence to the contrary, I think we're finally seeing an emerging consensus in support of the proposed approach, be it so long as the deadlock is ultimately resolved. Well, if rough consensus emerges for a non-deadlocked pinning design, with no substantive unaddressed objections, then the deadlock goes away, and we get to move forward to writing the consensus text, with a bit of the usual bikeshedding, and will soon be done. -- Viktor. From nobody Wed Oct 17 06:19:34 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C88A7130E83 for ; Wed, 17 Oct 2018 06:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yizkREBoxM8 for ; Wed, 17 Oct 2018 06:19:23 -0700 (PDT) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50D61130E08 for ; Wed, 17 Oct 2018 06:19:23 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id p143-v6so8737892lfp.13 for ; Wed, 17 Oct 2018 06:19:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SiWZto5f8MZuz05rad1zYxbl2YQVdRvQUE9qTR1FJkQ=; b=VOVelg7J92iILbmNMDCEzDuxvzJSpooX42PQFbJeKKPgQkXM1akOxg6IdvIDU8sUik TrA7xESSBV3vkfJPwOo6H2agGqAE6ihJNmzecFleWLnKnnA3flv+LF322ky7MD4O4/Xz 8EZWbl3IrKijZ7y1x1wGxvIy6OIbxkLGO5IlfFjuRFf2LsJzBpwDhSGrVxLsaG6od9Vp 4fihTpA2rOMC24x70klC1L1SWvnw+YAuuv4/+E0+2N3GPUIztCzG6dO5JZmsle4bm+8C E9IYgIohHoyTvT5Rsxuxj442lPyNISF4CxTGESVT+Jga2i/qP4rIy8yrCvPkdy/okws6 NnWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SiWZto5f8MZuz05rad1zYxbl2YQVdRvQUE9qTR1FJkQ=; b=ryUXxsqp86McYN/TFbBp/UQnrmfoUgNIuRtR4MSSRcmSF+dMKf+b8A4BB7hcaG6dJH HEFe5P7Y1/V4q3c5UXh+aI9Yg+9GAfOll+LJm15oGFkeM0qoaBMfEIjxDmeqeBiY11cG zUmsEQbI3p6ul/T0r2cubOlS1IVD55s0ms2ZvJGQ+IxPQa0yIbeMHrk4FyRf615LivNi wG1oX2EyLIGGhsJhygEoH9gLPqi6RE3jwiqJztwjvFcrAi3cXE8xctY94MSlV/IyjDJG V68F1qMzlPrZGmsnzDi/Ybwsdc5ve6gp/WUWZ4EgvWctY8DqcxQIV24yRNmxZirIh6Et EgDg== X-Gm-Message-State: ABuFfoieVECnmr0gpeZoYA83KjRu0NsuACicsoNEmloZ6bNiFdu4Fg/+ IRChbes5PSfGonzHIJJshmPkKxPLHfpuwOMC34CgBkL3 X-Google-Smtp-Source: ACcGV63x82eZ4wqkW0Fg5cxni4DWDNuC68yCSfk/zsqN9h8/QWCtU6x0TV6X9MzxssZhRHm/M9rrn4f1Dlng3tjR0nA= X-Received: by 2002:a19:a90f:: with SMTP id s15-v6mr15260065lfe.154.1539782361395; Wed, 17 Oct 2018 06:19:21 -0700 (PDT) MIME-Version: 1.0 References: <875zy1czbd.fsf@fifthhorseman.net> <20181017011515.GL7773@akamai.com> In-Reply-To: <20181017011515.GL7773@akamai.com> From: Eric Rescorla Date: Wed, 17 Oct 2018 06:18:27 -0700 Message-ID: To: Benjamin Kaduk Cc: Daniel Kahn Gillmor , "" Content-Type: multipart/alternative; boundary="000000000000af0a3205786c84bf" Archived-At: Subject: Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 13:19:33 -0000 --000000000000af0a3205786c84bf Content-Type: text/plain; charset="UTF-8" I'm responding to Ben here, because I think it's worth adding some clarity. However, I want to flag that I'm going to be rather short on time for the next few week and not able to spend a lot of time replying to traffic on this topic. Even more than usual, non-response to some point does not necessarily indicate agreement. On Tue, Oct 16, 2018 at 6:15 PM Benjamin Kaduk wrote: > (1) provides a channel for DANE records that is reliable in the absence of > an attack > I think this alone would be worthwhile -- and is the purpose I have always had in mind for the draft. > (2) reduces the ability of an attacker to cause the client to ignore the > server's authentication preference > > I think that just meeting the above two conditions could provide enough > value to merit publishing, even without attempting to add something > like: > > (3) allows the client to realistically hard-fail connections where DNSSEC > validation returns bogus or indeterminate. > I'm not sure I see a meaningful difference between (2) and (3), given that the mechanism for (2) is likely (3). > Getting (1) is probably trivial (though with middleboxes you never > know), and it seems fairly clear that a pinning scheme can provide (2). > Yes, the question is whether such a scheme is worth the other costs that it imposes (in particular, hostile pinning, and in the version that people have currently proposed, the ability to break yourself by inconsistent deployments, though that's at least conceivable fixable). In case it's not clear, I don't agree with Viktor's "no substantial issues have been raised" claim. -Ekr --000000000000af0a3205786c84bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm responding to Ben here, because I think it= 9;s worth adding some clarity.
However, I want to flag that I'= ;m going to be rather short on time for the next
few week and not= able to spend a lot of time replying to traffic on this
topic. E= ven more than usual, non-response to some point does not
necessar= ily indicate agreement.

<= div dir=3D"ltr">On Tue, Oct 16, 2018 at 6:15 PM Benjamin Kaduk <bkaduk@akamai.com> w= rote:
(1) provides a channel for DANE records that is reliable in the absence of<= br> =C2=A0 =C2=A0 an attack

I think this al= one would be worthwhile -- and is the purpose I have always had
i= n mind for the draft.

=C2=A0
(2) reduces the ability of an attacker to cause the client to ignore the =C2=A0 =C2=A0 server's authentication preference

I think that just meeting the above two conditions could provide enough
value to merit publishing, even without attempting to add something
like:

(3) allows the client to realistically hard-fail connections where DNSSEC =C2=A0 =C2=A0 validation returns bogus or indeterminate.

I'm not sure I see a meaningful difference between (2= ) and (3), given
that the mechanism for (2) is likely (3).


Getting (1) is probably trivial (though with middleboxes you never
know), and it seems fairly clear that a pinning scheme can provide (2).
=

Yes, the question is whether such a scheme= is worth the other costs that
it imposes (in particular, hostile= pinning, and in the version that people
have currently proposed,= the ability to break yourself by inconsistent
deployments, thoug= h that's at least conceivable fixable). In case it's
not = clear, I don't agree with Viktor's "no substantial issues have= been
raised" claim.

-Ekr
=
--000000000000af0a3205786c84bf-- From nobody Wed Oct 17 07:41:12 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20648130DDE for ; Wed, 17 Oct 2018 07:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.765 X-Spam-Level: X-Spam-Status: No, score=-0.765 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNZFmkheKXD9 for ; Wed, 17 Oct 2018 07:40:32 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2008130DE0 for ; Wed, 17 Oct 2018 07:40:29 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.23/8.16.0.23) with SMTP id w9HEWO3J011785; Wed, 17 Oct 2018 15:40:28 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=QK159zXvoIS+Kr2mquh8gROyHfrkgkDJh8xUtFpV4LM=; b=hWbsZ45cLYrECQDbU7vKqvsxTwnFCPmumNrWDAi9daVSWtOiJXhzbcNK2I3QSGJ20nht vU2vCjP6fi3/MLPTO0xrWsBMziehEkf4ZB/CcMdqK4mFQd4C5N3NVmiZVoGLc58wnCac XDVXob9SRsaF43PheYHwpdCIn5DcqYSERjg+msD5D6yyUmi6D8JpAvSTfTQPktfyxW9R a70dlhHdCcrhTJErsbJ3ikpVFyTzKuULvgGyf+DCXdvmPhPYYXwoGYYwFKWpY3zYigeh XaBGFMrDv5mTSIHxZSLNW4ZMajefpEYB0Jal3faV7F1te6eoYRsVwUry4EUNsra1nNX6 Cw== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0b-00190b01.pphosted.com with ESMTP id 2n5kexu0d6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 17 Oct 2018 15:40:28 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w9HEZGia014640; Wed, 17 Oct 2018 10:40:28 -0400 Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint1.akamai.com with ESMTP id 2n3c1usq8a-1; Wed, 17 Oct 2018 10:40:28 -0400 Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 190331FCDC; Wed, 17 Oct 2018 14:40:26 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1gCmzp-00058G-Hb; Wed, 17 Oct 2018 09:40:25 -0500 Date: Wed, 17 Oct 2018 09:40:25 -0500 From: Benjamin Kaduk To: Eric Rescorla Cc: "" Message-ID: <20181017144025.GN7773@akamai.com> References: <875zy1czbd.fsf@fifthhorseman.net> <20181017011515.GL7773@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-16_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810170126 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-16_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810170126 Archived-At: Subject: Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 14:40:35 -0000 On Wed, Oct 17, 2018 at 06:18:27AM -0700, Eric Rescorla wrote: > I'm responding to Ben here, because I think it's worth adding some clarity. > However, I want to flag that I'm going to be rather short on time for the > next > few week and not able to spend a lot of time replying to traffic on this > topic. Even more than usual, non-response to some point does not > necessarily indicate agreement. > > On Tue, Oct 16, 2018 at 6:15 PM Benjamin Kaduk wrote: > > > (1) provides a channel for DANE records that is reliable in the absence of > > an attack > > > > I think this alone would be worthwhile -- and is the purpose I have always > had > in mind for the draft. It's interesting to hear that, as I seem to recall a lot of discussion about how a security mechanism that folds in the presence of an attack ... isn't really a security mechanism. So while I could concoct a few scenarios in which just (1) would be *useful*, the main one that comes to mind isn't really a security mechanism, but would rather be part of a reporting mechanism for seeing what kind of DANE penetration is possible. Well, and I guess any case where the client has some other reason to expect to see this extension and choke if it's absent, such as a "greenfield" case or application-level pinning. So I'm curious what kind of use case(s) you had in mind for just the transport aspect. > > > > (2) reduces the ability of an attacker to cause the client to ignore the > > server's authentication preference > > > > I think that just meeting the above two conditions could provide enough > > value to merit publishing, even without attempting to add something > > like: > > > > (3) allows the client to realistically hard-fail connections where DNSSEC > > validation returns bogus or indeterminate. > > > > I'm not sure I see a meaningful difference between (2) and (3), given > that the mechanism for (2) is likely (3). Mostly I'm just claiming that the "realistically" in (3) is weasel-words that we don't need to get involved with at the protocol level. Whether or not to hard-fail is an application decision that we don't need to mandate. > > > Getting (1) is probably trivial (though with middleboxes you never > > know), and it seems fairly clear that a pinning scheme can provide (2). > > > > Yes, the question is whether such a scheme is worth the other costs that > it imposes (in particular, hostile pinning, and in the version that people > have currently proposed, the ability to break yourself by inconsistent > deployments, though that's at least conceivable fixable). In case it's > not clear, I don't agree with Viktor's "no substantial issues have been > raised" claim. Seeing as you are busy the next few weeks, perhaps I can ask the chairs to go through the email history and summarize these substantial issues that have been raised -- I am not confident that I could reproduce them from memory, myself. -Ben From nobody Wed Oct 17 08:10:58 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0441286D9 for ; Wed, 17 Oct 2018 08:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqQwgzNxv5fi for ; Wed, 17 Oct 2018 08:10:54 -0700 (PDT) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9C8A130DDE for ; Wed, 17 Oct 2018 08:10:53 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id 84-v6so16706449qkf.0 for ; Wed, 17 Oct 2018 08:10:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QdX37VZfmJZtQeOq0Wn9SrsUDcaIg82Zivzj1ukh5a0=; b=XPadG4Hr3xDitjPnG1EomE0bnx2+Hpibr9r5zXZPOD3iZFTLsLZ/S1lNPTlo9xbDwG rUSOS7Z5HMjxV4gYpLIIp9eSJ/uHnbsZVXD5yxXTMBB9Yd2lV5z/3r7U/gCGxPOXkoiy fVlvOlYQuV4m34MFIOl8zs+ehs3/DP8AWgzwM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QdX37VZfmJZtQeOq0Wn9SrsUDcaIg82Zivzj1ukh5a0=; b=eiQnKG3qYwPi3LqLy79V0U1anT/jg2OJuBG9GO41JcWVtm0dtMBp5b1JM6BJ1n0oY8 NYmqtrzmVyI7a90PkJMWiIbjx/dC17mC+/BLp32vmQ2F2tMKbss+zgZMrrS7crXCZbGK f/dA2rdRMV7Nu9sUq7SSR6W5/NBWHEMObK/zZO98kKBz+JHeGp2fDCFebSaRh36rGjb+ VY8ANXp0QF8sYOFkHMhYMmgMzCdRGlvvjdsQvxHM63irDBrDJDmWZg4gaq5SmmhRRer6 zdHvePlGreJ9PyQMgraRoua92RMvwRWiBmnjpRRMJQhxQEiLMHiCAYEfWqW/Lut5AENz gYZA== X-Gm-Message-State: ABuFfog5otOKrloXhCqDiXyEfw+IOLVhaFmWpj0IvTA5QLVzNgEl8BgJ nSTvgKdV3yQxBQqB3mBvoL4F6Q== X-Google-Smtp-Source: ACcGV61Zie5Xh87gcRtrZXj4eS550B/4FvaQCqbHFwMtsAIsbcsBmXJMz+H6n/WxXDN/BBWuUrdZaA== X-Received: by 2002:a37:cc1b:: with SMTP id r27-v6mr25132267qki.272.1539789052983; Wed, 17 Oct 2018 08:10:52 -0700 (PDT) Received: from [172.16.0.18] ([96.231.224.191]) by smtp.gmail.com with ESMTPSA id s6-v6sm12048089qtk.4.2018.10.17.08.10.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Oct 2018 08:10:51 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sean Turner In-Reply-To: <20181017144025.GN7773@akamai.com> Date: Wed, 17 Oct 2018 11:10:50 -0400 Cc: Eric Rescorla , tls@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <1A68D66E-A836-44E3-BC23-1E3B41234EC8@sn3rd.com> References: <875zy1czbd.fsf@fifthhorseman.net> <20181017011515.GL7773@akamai.com> <20181017144025.GN7773@akamai.com> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 15:10:56 -0000 > On Oct 17, 2018, at 10:40, Benjamin Kaduk wrote: > > Seeing as you are busy the next few weeks, perhaps I can ask the chairs > to go through the email history and summarize these substantial issues > that have been raised -- I am not confident that I could reproduce them > from memory, myself. We will do that and more. It will not be done tomorrow though. spt From nobody Wed Oct 17 08:24:19 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58A3130DE4 for ; Wed, 17 Oct 2018 08:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56fiUK2AJBvp for ; Wed, 17 Oct 2018 08:24:15 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4BDA130DEE for ; Wed, 17 Oct 2018 08:24:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 224E7BE49; Wed, 17 Oct 2018 16:24:12 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ko2kkpZqBHbH; Wed, 17 Oct 2018 16:24:12 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D0E03BE39; Wed, 17 Oct 2018 16:24:11 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1539789851; bh=qQRVALiEBBNKUQYIxF78Nj+twwRc7Yzz5dpmuUZR0GY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=U/TDAxMEkVcsnM8zDv5WFiwNnN3AhLKIG9xD78OFc9BU5aXla6MS9kRqkc1utirWU SnnNQNWFx+NuScplEHmgquFUdQRdPsD70prfkYcx5JFEYWIVZHZddmKaahqr/qyQ5Z mYHuJhLBUazTrPE6aIaYX3f27tJdrLOO12V5D4xQ= To: Sean Turner , tls@ietf.org References: <9DE64F7F-4740-4410-A004-373D8919920B@sn3rd.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Wed, 17 Oct 2018 16:24:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <9DE64F7F-4740-4410-A004-373D8919920B@sn3rd.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HnEduMsW17hgR5ZEr2ZU94N66gcylz0OB" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-sni-encryption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 15:24:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HnEduMsW17hgR5ZEr2ZU94N66gcylz0OB Content-Type: multipart/mixed; boundary="duaXL0czBAepQOU3jXL74gnPctyWNoICP"; protected-headers="v1" From: Stephen Farrell To: Sean Turner , tls@ietf.org Message-ID: Subject: Re: [TLS] WGLC for draft-ietf-tls-sni-encryption References: <9DE64F7F-4740-4410-A004-373D8919920B@sn3rd.com> In-Reply-To: <9DE64F7F-4740-4410-A004-373D8919920B@sn3rd.com> --duaXL0czBAepQOU3jXL74gnPctyWNoICP Content-Type: multipart/mixed; boundary="------------6185F918BB8D6F049A036EED" Content-Language: en-GB This is a multi-part message in MIME format. --------------6185F918BB8D6F049A036EED Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, I think this is more-or-less ready and I support publication. My comments below, none of which are show-stoppers but they might be worth a look. Cheers, S. 1. Shouldn't there be some mention of CT here somewhere? Say if we have a good solution, but the hidden service's cert is in CT logs, then an adversary can find those, and see what it gets from DNS for those names (from different vantage points) and how that correlates with addresses. And if the certs for hidden services are special in any way, that gets worse. (Implying that we don't want the certs for the hidden services to be special in any way I guess?) 2. HTTP fronting - I guess the situation has changed a bit with respect to this over the time that the draft has been evolving. Do we want to note that? 3. As a process-issue, I'm not sure if it'd be better or worse to send this for publication now or wait until the esni work has progressed some more. I don't mind either way myself, but I guess the question'll be asked if we do shoot it forward now, (given that some people apparently dislike this kind of RFC;-). It'd be no harm to have the answer on the list if that's the plan - so why publish now, given that esni is under development? nits: - abstract: might be worth saying that we don't expect solutions to necessarily meet all requirements here. (That's stated in the security considerations, but could be worth adding here.) - 2.1: is it worth noting debugging tools like wireshark here? - 2.2: Are all of the things mentioned in 2.1 "abuses"? I'm not sure everyone would agree. It might be worth doing s/abuses/uses and abuses/ here to avoid a fuss at IETF LC time. - 2.2: "make it much harder" is maybe overstated? - 3.4: There's the inevitable issue with not sticking out. That being that it tends to increase the centralisation of the Internet, in this case reducing the number of entities to which pressure needs to be applied by the adversary. Worth a mention here? --------------6185F918BB8D6F049A036EED Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG +48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6 TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G +po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+ q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36 ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ 4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73 gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC 98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl 74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2 B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI /awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0 b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7 NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63 6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a 5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO 8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9 tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn 20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8 /iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU 6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6 Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5 wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9 g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2 Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7 O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC 6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2 D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ /Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96 Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P /1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8 Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5 SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2 oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS /qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DJ121 -----END PGP PUBLIC KEY BLOCK----- --------------6185F918BB8D6F049A036EED-- --duaXL0czBAepQOU3jXL74gnPctyWNoICP-- --HnEduMsW17hgR5ZEr2ZU94N66gcylz0OB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlvHVBoACgkQWrL68XsX K+pXkRAAouCB2Dz9eEB/LXElWbDLUSmsegnTcs1tPBK+m+Eqs5S6yCVWxl040OFm sh264lOml4xdJe9bPBi+Hx7MfbjzuO5jRZCQEIVq/ZKWNyHGhK6YhmegtAjdaZRx K+DeSFTQSvrrmRbYE7W8PEKiBAdtMXYyFWr6wNBGnHYmIyoWoIAaZMyEORBgtnJm v9xxUXFraRLn+nAe6wFZ3Bd+hjoN3yiMh0FUmcuRslb5ZsGmRLtR6gzXgEFTHYEe 4r6mt5VtFwsMpl7p6vI5AVKXHPBYtzeh56jnc6s0f/ljrs33T2AKpM+KRvKhtHA6 pdCbBbeCDeQ7TetCYCg5gsxB280p5LilxoVgI6zdi5tHV6kSBzHW9j+RnIxMg2Le wNcwlQi5yKO8HZcso2KtUUKihydaoK5fyhZ87bi+ucqZPlbCNKOu0YmKhfa2tU8d G+/AzZvTF6MHq/DpTy/eZ/jWcQKZ83H92OBu3T6cWl+tJhXWxphJ6rPyfFooYqkd ffsm366N/S977dpIkHTI+MZYaXeWdCpjdzssXXIixW1Bf10kwmB+H1gSpX+Mb08r 3hy/NcjnJe4Bzy5sICUvP/1GcZxJCayx/Jwy8Xs1nKNntV/L9rtfEmNjUJ/uG8QC o6MGf4MfmNBNWk2cLEKopXV7ESIT1QJZ82x8cm8T4XUpGy2kq70= =sPS+ -----END PGP SIGNATURE----- --HnEduMsW17hgR5ZEr2ZU94N66gcylz0OB-- From nobody Wed Oct 17 08:25:03 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E70130EA7 for ; Wed, 17 Oct 2018 08:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQYi7QVl07Xp for ; Wed, 17 Oct 2018 08:24:51 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A9CF130EE3 for ; Wed, 17 Oct 2018 08:24:51 -0700 (PDT) Received: from [192.168.1.161] (unknown [192.168.1.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id C2DAA2CB02 for ; Wed, 17 Oct 2018 11:24:50 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Viktor Dukhovni In-Reply-To: Date: Wed, 17 Oct 2018 11:24:49 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: "" Message-Id: <9165DEBE-D12D-4D8B-B829-0E9B64E481EF@dukhovni.org> References: <875zy1czbd.fsf@fifthhorseman.net> <20181017011515.GL7773@akamai.com> To: "" X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 15:25:02 -0000 > On Oct 17, 2018, at 9:18 AM, Eric Rescorla wrote: >> (1) provides a channel for DANE records that is reliable in the = absence of >> an attack >=20 > I think this alone would be worthwhile -- and is the purpose I have = always had > in mind for the draft. Well, a security mechanism that "works in the absence of attack" looks rather pointless to me. Cleartext transmission with no authentication also works in the absence of attack, and yet does not a security = mechanism make. The -07 draft covers only the use-cases where the extension is mandatory (pin interval of "from now and forever"), all the other = use-cases fail. > I don't agree with Viktor's "no substantial issues have been > raised" claim. Then, please raise them! Just saying "hostile pinning, QED" is not a substantial issue. We've argued in detail that: 1. This was never the real problem with e.g. HPKP, and the credible concern is footgun, not "hostile pinning". We've shown that footgun is not a substantive problem here. 2. We've also argued that even with "hostile pinning" the domain owner recovers if he is able to deploy the extension (unlike never known keys with HPKP). And clients that can do real DNSSEC lookups can always pay the extra latency, and if necessary do DNS over TLS to 1.1.1.1, et. al. to get around last-mile barriers, and thus clear any unauthorized pins even prior to server-side extension support. =20 3. And, frankly, I find hostile pinning not a credible threat, and to the extent that it yields client-visible side-effects of major prior compromise, I see any resulting tamper-evidence as a feature, not a bug. =20 4. Lastly, if nevertheless the "hostile pinning" concern is what makes or breaks consensus on this draft, then we're OK with introducing exponential scaling-up (over time) of max pin TTL, which will keep it reasonably low until the last few years of the scaling horizon. =46rom where I stand, mere repetition of "hostile pinning QED" frankly = no longer counts as a responsive objection. :-( Likewise, mere repetition of a claimed benefit from downgradable DANE signalling, without explaining why or how this is useful, is also not a substantive argument to support a claim that the use-cases are served without downgrade protection. Which additional attacks does such signalling militate, beyond those already handled by WebPKI? There would need to be a use-case where: * The extension is not mandatory. * Just WebPKI alone does not protect the server. * WebPKI + downgradable DANE signal protects the server. I've not seen any such use-case. --=20 Viktor. From nobody Wed Oct 17 10:02:46 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2FC0130E03 for ; Wed, 17 Oct 2018 10:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id layUK95H0_3e for ; Wed, 17 Oct 2018 10:02:41 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1BEE130DC9 for ; Wed, 17 Oct 2018 10:02:40 -0700 (PDT) Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 42Zz4s6y5Nzs9; Wed, 17 Oct 2018 19:02:37 +0200 (CEST) X-purgate-ID: 152705::1539795758-00000211-1BEB3BC6/0/0 X-purgate-size: 4268 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 42Zz4r6bmLzGqdT; Wed, 17 Oct 2018 19:02:36 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id DA9D1404C; Wed, 17 Oct 2018 19:02:36 +0200 (CEST) In-Reply-To: <9DE64F7F-4740-4410-A004-373D8919920B@sn3rd.com> References: <9DE64F7F-4740-4410-A004-373D8919920B@sn3rd.com> To: Sean Turner Date: Wed, 17 Oct 2018 19:02:36 +0200 (CEST) CC: tls@ietf.org Reply-To: mrex@sap.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20181017170236.DA9D1404C@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-sni-encryption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 17:02:45 -0000 Sean Turner wrote: > > This is the working group last call for the > "Issues and Requirements for SNI Encryption in TLS" > draft available at > http://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/. > Please review the document and send your comments to the list > by 2359 UTC on 31 October 2018. I think the idea of encrypted SNI is inherently flawed in its concept. If anyone really thinks that there should be a scheme where a server's hostname is no longer transfered in a cleartext (including TLS extension SNI), then first of all a *NEW* distinct URI method should be defined for that purpose, e.g. "httph://" as a reliable indicator to the client processing this URI, that the hostname from this URI is not supposed to be sent over the wire in the clear *anywhere*. As it is, there are a number of servers which desperately require the presence of TLS extension SNI, or will fail TLS handshakes either by choking and dropping connections (Microsoft IIS 8.5+) or by very unhelpful alerts (several others), and also HTTP/2.0 requires unconditional cleartext presence of TLS extension SNI. Any kind of heuristics-based approach for clients to guess whether or not to send TLS extension SNI is flawed from the start. If a network middlebox can make a client present a cleartext TLS extension SNI by refusing connections without cleartext TLS extension SNI, the entire effort becomes pretty useless. It is necessary that the client knows reliably that a hostname must not be sent in the clear, including when the connection fails for unknown reasons, and only a new URI method will reliably provide such a clear distinction. I also believe the draft is contains flawed assumptions and misleading descriptions of facts and history. e.g. Section 2.2 "The common name component of the server certificate generally exposes the same name as the SNI. In TLS versions 1.0 [RFC2246], 1.1 [RFC4346], and 1.2 [RFC5246]"" SubjectAltName attributes, unless you were hiding under some stone with no internet acces for more than a decade... rfc2818 "HTTP over TLS" section 3.1 "Server Endpoint Identification" described retroactively, what kind of name matching TLS clients Browsers were doing -- and what all TLS clients are supposed to be doing on a TLS server certificate. https://tools.ietf.org/html/rfc2818#section-3 This approach was recommended for use in other protocols besides HTTP over TLS by RFC 6125. By sending TLS extension SNI in the clear to a server, the client tells that server: I am going to perform an rfc2818 "HTTP over TLS" section 3.1 "Server Endpoint Identification" matching -- and if you have several different TLS server certificates to choose from, you better send me one that is going to succeed this specific matching, which I am going to perform on your TLS ServerCertificate response. The TLS server certificate could only be conveyed *IN*THE*CLEAR* in SSLv3, could be conveyed only in the clear in TLSv1.0, when TLS extension SNI was proposed in rfc3546 to allow virtual hosting from HTTP to work with HTTPS, and could be conveyed only in the clear in TLSv1.2, when SNI was rev'ed by rfc6066. In protocol version SSLv3->TLSv1.2, encryption keys are only established *AFTER* successful authentication of the server through its server certificate. So it was obviously impossible to encrypt the information whose only purpose it was to allow the server to decide *which* TLS Server certificate to use for authentication (hen-and-egg). DH_anon cipher suites do not have a server certificate handshake message, and they are well-known to be completely insecure to man-in-the-middle attacks anyways, which is why TLSv1.2 (rfc5246) says this about them: The following cipher suites are used for completely anonymous Diffie-Hellman communications in which neither party is authenticated. Note that this mode is vulnerable to man-in-the- middle attacks. Using this mode therefore is of limited use: These cipher suites MUST NOT be used by TLS 1.2 implementations unless the application layer has specifically requested to allow anonymous key exchange. -Martin From nobody Wed Oct 17 14:49:25 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 438A1130E27 for ; Wed, 17 Oct 2018 14:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCYQiXsBH9vM for ; Wed, 17 Oct 2018 14:49:18 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF862130F20 for ; Wed, 17 Oct 2018 14:49:17 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id v7-v6so25784660ljg.5 for ; Wed, 17 Oct 2018 14:49:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/o+ZDruOtvxTkHSLVJdpxEVn1L5ZrgaSEHzvHtoR9n0=; b=bWIl94yENuZr+3EiSQ+VYnT/NpJXA8XHk3Rso6ab1Wg9JYfkKWPiJd16r9UX6cBVOp WOWSGvMbfOHFE5FtVQzmgvpIRswq+d/6oKIhgGXysGvlY7H9aSPlCkhoFIBjfd+GvZ52 sjRIJOi3/vhj26lULRvIzaw6i4ydEvBsobEd9L3Vgrg/6EVW82tyyTpAKy/Y3MTbuTOb YNrSmTurG74284F+5Du+GOMfJr3LLIJBFaDVFi9m9oC9o1UEOSnM7SLXAYUssFqgyoGM 0AybGpnII/XZhste5hZgxlhi1I/spqBAGX7UIGH7RbQGIVmWVPd8vzhaxrOzv+nukfBk QhTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/o+ZDruOtvxTkHSLVJdpxEVn1L5ZrgaSEHzvHtoR9n0=; b=pr0JxNQb6Mz0KLkNpetYKdyTPV0bqStrTeiZdu8mu97ZVrPOFrUzQEDg2ws4mMEwg8 D7fOiih7AEbTfFRCC1BC9yAIpVdY4gKVYzR/uKbNKe6ezux0EW5qElA1Mmqiw/tHKvgF 5gfps4FJ4116vew5zLKc6zuoeAnt1IAmEproEjfYJIvwxKRQZ0q7GBQ66KQwOvLCSUo7 T22rlGbe1mM0KbmSZdIZzJ+8/Y05MDj1nUMmPQIYdrOrtYs5uJZihU/oetDaN4yRsQEW lVZ66FL3eKTeydeXwoNVcaz560XL2QdwdtjoRsjejZrdSbiiYwZUdPVuzFlAhsSaXrrY eVww== X-Gm-Message-State: ABuFfog+Dg+vfwMrcX8dVk5IJrSbid2iDqYmw0yvqozKblUn2LcEqyQn I9+s5BcVVoGRWI0cv/cQWPQvvnJlNpIbwMnV/OZFVZrM X-Google-Smtp-Source: ACcGV61NbcXQRr2hW65txOI9t4XWiQCRsCrN4QTBwFDt6Y6UVGXzzPL/Rsq03C7pHSBWEP/J3EVDA2f6+0AkP301S+I= X-Received: by 2002:a2e:7017:: with SMTP id l23-v6mr13378220ljc.160.1539812955922; Wed, 17 Oct 2018 14:49:15 -0700 (PDT) MIME-Version: 1.0 References: <875zy1czbd.fsf@fifthhorseman.net> <20181017011515.GL7773@akamai.com> <20181017144025.GN7773@akamai.com> In-Reply-To: <20181017144025.GN7773@akamai.com> From: Eric Rescorla Date: Wed, 17 Oct 2018 14:48:47 -0700 Message-ID: To: Benjamin Kaduk Cc: "" Content-Type: multipart/alternative; boundary="000000000000424087057873a493" Archived-At: Subject: Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 21:49:24 -0000 --000000000000424087057873a493 Content-Type: text/plain; charset="UTF-8" On Wed, Oct 17, 2018 at 7:40 AM Benjamin Kaduk wrote: > On Wed, Oct 17, 2018 at 06:18:27AM -0700, Eric Rescorla wrote: > > I'm responding to Ben here, because I think it's worth adding some > clarity. > > However, I want to flag that I'm going to be rather short on time for the > > next > > few week and not able to spend a lot of time replying to traffic on this > > topic. Even more than usual, non-response to some point does not > > necessarily indicate agreement. > > > > On Tue, Oct 16, 2018 at 6:15 PM Benjamin Kaduk > wrote: > > > > > (1) provides a channel for DANE records that is reliable in the > absence of > > > an attack > > > > > > > I think this alone would be worthwhile -- and is the purpose I have > always > > had > > in mind for the draft. > > It's interesting to hear that, as I seem to recall a lot of discussion > about how a security mechanism that folds in the presence of an attack > ... isn't really a security mechanism. > > So while I could concoct a few scenarios in which just (1) would be > *useful*, the main one that comes to mind isn't really a security > mechanism, but would rather be part of a reporting mechanism for seeing > what kind of DANE penetration is possible. Well, and I guess any case > where the client has some other reason to expect to see this extension > and choke if it's absent, such as a "greenfield" case or > application-level pinning. So I'm curious what kind of use case(s) you had > in mind for just the transport aspect. > Given that you just described at least two use cases, I feel like you've answered your own question here. -Ekr > > > > > > > (2) reduces the ability of an attacker to cause the client to ignore > the > > > server's authentication preference > > > > > > I think that just meeting the above two conditions could provide enough > > > value to merit publishing, even without attempting to add something > > > like: > > > > > > (3) allows the client to realistically hard-fail connections where > DNSSEC > > > validation returns bogus or indeterminate. > > > > > > > I'm not sure I see a meaningful difference between (2) and (3), given > > that the mechanism for (2) is likely (3). > > Mostly I'm just claiming that the "realistically" in (3) is weasel-words > that we don't need to get involved with at the protocol level. Whether > or not to hard-fail is an application decision that we don't need to > mandate. > > > > > > Getting (1) is probably trivial (though with middleboxes you never > > > know), and it seems fairly clear that a pinning scheme can provide (2). > > > > > > > Yes, the question is whether such a scheme is worth the other costs that > > it imposes (in particular, hostile pinning, and in the version that > people > > have currently proposed, the ability to break yourself by inconsistent > > deployments, though that's at least conceivable fixable). In case it's > > not clear, I don't agree with Viktor's "no substantial issues have been > > raised" claim. > > Seeing as you are busy the next few weeks, perhaps I can ask the chairs > to go through the email history and summarize these substantial issues > that have been raised -- I am not confident that I could reproduce them > from memory, myself. > > -Ben > --000000000000424087057873a493 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed= , Oct 17, 2018 at 7:40 AM Benjamin Kaduk <bkaduk@akamai.com> wrote:
On Wed, Oct 17, 2018 at 06:18:27AM -0700, Eric Rescorla wrote:
> I'm responding to Ben here, because I think it's worth adding = some clarity.
> However, I want to flag that I'm going to be rather short on time = for the
> next
> few week and not able to spend a lot of time replying to traffic on th= is
> topic. Even more than usual, non-response to some point does not
> necessarily indicate agreement.
>
> On Tue, Oct 16, 2018 at 6:15 PM Benjamin Kaduk <bkaduk@akamai.com> wrote:
>
> > (1) provides a channel for DANE records that is reliable in the a= bsence of
> >=C2=A0 =C2=A0 =C2=A0an attack
> >
>
> I think this alone would be worthwhile -- and is the purpose I have al= ways
> had
> in mind for the draft.

It's interesting to hear that, as I seem to recall a lot of discussion<= br> about how a security mechanism that folds in the presence of an attack
... isn't really a security mechanism.

So while I could concoct a few scenarios in which just (1) would be
*useful*, the main one that comes to mind isn't really a security
mechanism, but would rather be part of a reporting mechanism for seeing
what kind of DANE penetration is possible.=C2=A0 Well, and I guess any case=
where the client has some other reason to expect to see this extension
and choke if it's absent, such as a "greenfield" case or
application-level pinning.=C2=A0 So I'm curious what kind of use case(s= ) you had
in mind for just the transport aspect.

= Given that you just described at least two use cases, I feel like you'v= e answered
your own question here.

-Ekr<= /div>


>
>
> > (2) reduces the ability of an attacker to cause the client to ign= ore the
> >=C2=A0 =C2=A0 =C2=A0server's authentication preference
> >
> > I think that just meeting the above two conditions could provide = enough
> > value to merit publishing, even without attempting to add somethi= ng
> > like:
> >
> > (3) allows the client to realistically hard-fail connections wher= e DNSSEC
> >=C2=A0 =C2=A0 =C2=A0validation returns bogus or indeterminate.
> >
>
> I'm not sure I see a meaningful difference between (2) and (3), gi= ven
> that the mechanism for (2) is likely (3).

Mostly I'm just claiming that the "realistically" in (3) is w= easel-words
that we don't need to get involved with at the protocol level.=C2=A0 Wh= ether
or not to hard-fail is an application decision that we don't need to mandate.

>
> > Getting (1) is probably trivial (though with middleboxes you neve= r
> > know), and it seems fairly clear that a pinning scheme can provid= e (2).
> >
>
> Yes, the question is whether such a scheme is worth the other costs th= at
> it imposes (in particular, hostile pinning, and in the version that pe= ople
> have currently proposed, the ability to break yourself by inconsistent=
> deployments, though that's at least conceivable fixable). In case = it's
> not clear, I don't agree with Viktor's "no substantial is= sues have been
> raised" claim.

Seeing as you are busy the next few weeks, perhaps I can ask the chairs
to go through the email history and summarize these substantial issues
that have been raised -- I am not confident that I could reproduce them
from memory, myself.

-Ben
--000000000000424087057873a493-- From nobody Wed Oct 17 15:11:37 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D245130E06 for ; Wed, 17 Oct 2018 15:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fncW0pEa3nBe for ; Wed, 17 Oct 2018 15:11:31 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EADA2130E1C for ; Wed, 17 Oct 2018 15:11:30 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id y71-v6so25817157lje.9 for ; Wed, 17 Oct 2018 15:11:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=o7KTtEJ+7eVbbxPK8W7+nqPsJwd0bxqPFRNdfe09TCE=; b=hS9y87q47b410RZKRyiF3v+QxJsJHt0tSJWckpyMPV8zqUwLpcR/u/5JaqsHwGukvO vLZY89EP+8MHxmbGIx7ZGhto6Gt5HoCds8GAZa4NXxEGsNgJhuDO1KveZX4aDrUXGuZi mmnak/oLCXkeBSWZ8AbEQ2jRA8A44DifRierwjOM3r9xU6Q4K/WOIrG+ZfUVZkcyogAH 6dxeAKz7Wr4r+mLOik9v7i8IfTJRTiFsP16e1WQRTgunHhhu8WRt3Tv/DrWlvZJgqCCJ 6pkxOFPf7OYJqDBvlxhMGCaGKheQoY89kLi4kt+tgSB4zmZzJgKmBI2/zjVixtWgGsiP ix6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=o7KTtEJ+7eVbbxPK8W7+nqPsJwd0bxqPFRNdfe09TCE=; b=lzARJtVdCMQ47TUN75dOTXTWcm34DnIDwVq2DTKVlUYdv81c2FATWoABii30vJZRsr jIA9EpONxVLb/s/GeUWN5kjMu3uDgmKYLbGBJF8+oeLgrcyZ5yGDLo0kaY/qzbz8rPOy CffOs1ff1tt7DFTF7+DfjAW3lGQLr89oYXcA5/H8jk1LK6PJH7YJYK7qv/hhuJJxFSRm /gxkNlMbU6dzs4bI1V9xNw65hmG8AHOS3NO1QJJAfkiOAlS2peduU+goqGRka3Oc3iBa epRTj96sv1StNrin3V9pCdrbk1LPXMy6vAgLW/YTpu6ueFpoSqyauXEl1deE8w7o/HpQ DE7g== X-Gm-Message-State: ABuFfog3wVpEzUanV4pci/K3jqA1nyhwoCb4/JrBoyv4T/DXek/QbGob KBBaxfNpn4Bd9IIUllm70V+mBVSipKxBZLkI76XFUbcenzc= X-Google-Smtp-Source: ACcGV62Lf4WoyrpeLs/TwABc+n5nfPkmFwVGlynbkMKP7v1eXn0cgXob4kP4ZwutVuHRpvG40/7Gw098cm7BYM40H84= X-Received: by 2002:a2e:7017:: with SMTP id l23-v6mr13413497ljc.160.1539814289149; Wed, 17 Oct 2018 15:11:29 -0700 (PDT) MIME-Version: 1.0 References: <9DE64F7F-4740-4410-A004-373D8919920B@sn3rd.com> <20181017170236.DA9D1404C@ld9781.wdf.sap.corp> In-Reply-To: <20181017170236.DA9D1404C@ld9781.wdf.sap.corp> From: Eric Rescorla Date: Wed, 17 Oct 2018 15:10:52 -0700 Message-ID: To: mrex@sap.com Cc: Sean Turner , "" Content-Type: multipart/alternative; boundary="000000000000b99f34057873f39f" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-sni-encryption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 22:11:35 -0000 --000000000000b99f34057873f39f Content-Type: text/plain; charset="UTF-8" On Wed, Oct 17, 2018 at 10:03 AM Martin Rex wrote: > Sean Turner wrote: > > > > This is the working group last call for the > > "Issues and Requirements for SNI Encryption in TLS" > > draft available at > > http://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/. > > Please review the document and send your comments to the list > > by 2359 UTC on 31 October 2018. > > > I think the idea of encrypted SNI is inherently flawed in its concept. > It's pretty late to raise this point as we've had repeated consensus calls to work on this. If anyone really thinks that there should be a scheme where a server's > hostname is no longer transfered in a cleartext (including TLS extension > SNI), > then first of all a *NEW* distinct URI method should be defined for that > purpose, e.g. "httph://" as a reliable indicator to the client processing > this URI, that the hostname from this URI is not supposed to be sent > over the wire in the clear *anywhere* > > As it is, there are a number of servers which desperately require > the presence of TLS extension SNI, or will fail TLS handshakes either > by choking and dropping connections (Microsoft IIS 8.5+) or by > very unhelpful alerts (several others), and also HTTP/2.0 requires > unconditional cleartext presence of TLS extension SNI. Any kind of > heuristics-based approach for clients to guess whether or not to > send TLS extension SNI is flawed from the start. If a network > middlebox can make a client present a cleartext TLS extension SNI > by refusing connections without cleartext TLS extension SNI, > the entire effort becomes pretty useless. Yes, clients must not fall back to cleartext SNI in this case. It is necessary > that the client knows reliably that a hostname must not be sent > in the clear, including when the connection fails for unknown reasons, > and only a new URI method will reliably provide such a clear distinction. > I don't agree with this claim, given that we have a number of other proposed mechanisms for the client to know when ESNI is allowed, including DNS. It's true that middleboxes might block these requests, but https://tools.ietf.org/html/draft-ietf-tls-esni-01#section-6.2 has some material on this. Comments welcome. In any case, I don't see why a URI is better than DNS in this case.. > By sending TLS extension SNI in the clear to a server, the client > tells that server: I am going to perform an rfc2818 "HTTP over TLS" > section 3.1 "Server Endpoint Identification" matching I don't know where you get this from, given that RFC 6066 doesn't even cite 2818. In protocol version SSLv3->TLSv1.2, encryption keys are only established > *AFTER* successful authentication of the server through its server > certificate. So it was obviously impossible to encrypt the information > whose only purpose it was to allow the server to decide *which* TLS Server > certificate to use for authentication (hen-and-egg). > This isn't really correct: the mechanism for encrypting SNI itself would actually work fine in previous versions of TLS as well. It's just that you don't encrypt the *certificate* so that it wouldn't be useful -Ekr > --000000000000b99f34057873f39f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Oct 17, 2018 at 10:03 AM Martin Rex <mrex@sap.com> wrote:
Sean Turner <sean@sn3rd.com> wrote:
>
> This is the working group last call for the
> "Issues and Requirements for SNI Encryption in TLS"
> draft available at
> http://datatracker.ietf.org/doc/d= raft-ietf-tls-sni-encryption/.
> Please review the document and send your comments to the list
> by 2359 UTC on 31 October 2018.


I think the idea of encrypted SNI is inherently flawed in its concept.
<= /blockquote>

It's pretty late to raise this point as= we've had repeated consensus calls to
work on this.
If anyone really thinks that there should be a scheme where a server'= s
=C2=A0
hostname is no longer transfered in a cleartext (including TLS extension SN= I),
then first of all a *NEW* distinct URI method should be defined for that purpose,=C2=A0 e.g. "httph://"=C2=A0 as a reliable indicator to t= he client processing
this URI, that the hostname from this URI is not supposed to be sent
over the wire in the clear *anywhere*
=C2=A0
As it is, there are a number of servers which desperately require
the presence of TLS extension SNI, or will fail TLS handshakes either
by choking and dropping connections (Microsoft IIS 8.5+) or by
very unhelpful alerts (several others), and also HTTP/2.0 requires
unconditional cleartext presence of TLS extension SNI.=C2=A0 Any kind of heuristics-based approach for clients to guess whether or not to
send TLS extension SNI is flawed from the start.=C2=A0 If a network
middlebox can make a client present a cleartext TLS extension SNI
by refusing connections without cleartext TLS extension SNI,
the entire effort becomes pretty useless.

Y= es, clients must not fall back to cleartext SNI in this case.

= =C2=A0 It is necessary
that the client knows reliably that a hostname must not be sent
in the clear, including when the connection fails for unknown reasons,
and only a new URI method will reliably provide such a clear distinction.

I don't agree with this claim, given= that we have a number of other proposed
mechanisms for the clien= t to know when ESNI is allowed, including DNS.
It's true that= middleboxes might block these requests, but
material = on this. Comments welcome. In any case, I don't see why
a URI= is better than DNS in this case..

=C2=A0
By sending TLS extension SNI in the clear to a server, the client
tells that server:=C2=A0 I am going to perform an rfc2818 "HTTP over T= LS"
section 3.1 "Server Endpoint Identification" matching

I don't know where you get this from, given that = RFC 6066 doesn't
even cite 2818.



In protocol version SSLv3->TLSv1.2, encryption keys are only established=
*AFTER* successful authentication of the server through its server
certificate. So it was obviously impossible to encrypt the information
whose only purpose it was to allow the server to decide *which* TLS Server<= br> certificate to use for authentication (hen-and-egg).
<= br>
This isn't really correct: the mechanism for encrypting S= NI itself would actually work
fine in previous versions of TLS as= well. It's just that you don't encrypt
the *certificate*= so that it wouldn't be useful

-Ekr
<= div>

--000000000000b99f34057873f39f-- From nobody Wed Oct 17 16:41:18 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4386130E1A for ; Wed, 17 Oct 2018 16:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jve7Givzo_7z for ; Wed, 17 Oct 2018 16:41:12 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 946DD130E03 for ; Wed, 17 Oct 2018 16:41:12 -0700 (PDT) Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 42b7wk4Z4vzydN; Thu, 18 Oct 2018 01:41:10 +0200 (CEST) X-purgate-ID: 152705::1539819670-00000211-64696636/0/0 X-purgate-size: 5298 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 42b7wk23MTzGqb1; Thu, 18 Oct 2018 01:41:10 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 39D36404C; Thu, 18 Oct 2018 01:41:10 +0200 (CEST) In-Reply-To: References: <9DE64F7F-4740-4410-A004-373D8919920B@sn3rd.com> <20181017170236.DA9D1404C@ld9781.wdf.sap.corp> To: Eric Rescorla Date: Thu, 18 Oct 2018 01:41:10 +0200 (CEST) CC: mrex@sap.com, Sean Turner , "" Reply-To: mrex@sap.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20181017234110.39D36404C@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-sni-encryption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 23:41:16 -0000 Eric Rescorla wrote: > Martin Rex wrote: > > > Sean Turner wrote: > > > > > > This is the working group last call for the > > > "Issues and Requirements for SNI Encryption in TLS" > > > draft available at > > > http://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/. > > > Please review the document and send your comments to the list > > > by 2359 UTC on 31 October 2018. > > > > > > I think the idea of encrypted SNI is inherently flawed in its concept. > > > > It's pretty late to raise this point Nope, I've raised this *EVERY* time on the list when the dead horse was newly beaten. > >> As it is, there are a number of servers which desperately require >> the presence of TLS extension SNI, or will fail TLS handshakes either >> by choking and dropping connections (Microsoft IIS 8.5+) or by >> very unhelpful alerts (several others), and also HTTP/2.0 requires >> unconditional cleartext presence of TLS extension SNI. Any kind of >> heuristics-based approach for clients to guess whether or not to >> send TLS extension SNI is flawed from the start. If a network >> middlebox can make a client present a cleartext TLS extension SNI >> by refusing connections without cleartext TLS extension SNI, >> the entire effort becomes pretty useless. > > Yes, clients must not fall back to cleartext SNI in this case. Please give a clear deterministic algorithm how a client can tell apart a server that requires cleartext SNI from a server that does not want cleartext SNI. > > It is necessary > > that the client knows reliably that a hostname must not be sent > > in the clear, including when the connection fails for unknown reasons, > > and only a new URI method will reliably provide such a clear distinction. > > > > I don't agree with this claim, given that we have a number of other proposed > mechanisms for the client to know when ESNI is allowed, including DNS. DNS is a non-starter for several reasons. Ever heard of firewalled networks, private DNS universes and HTTP CONNECT proxies? Then the TLS implementation itself may be completely free of blocking network IO. > >> By sending TLS extension SNI in the clear to a server, the client >> tells that server: I am going to perform an rfc2818 "HTTP over TLS" >> section 3.1 "Server Endpoint Identification" matching > > I don't know where you get this from, given that RFC 6066 doesn't > even cite 2818. Simply to avoid a downref. I should not have to explain this to you. rfc2818, section 3.1: 3.1. Server Identity In general, HTTP/TLS requests are generated by dereferencing a URI. As a consequence, the hostname for the server is known to the client. If the hostname is available, the client MUST check it against the server's identity as presented in the server's Certificate message, in order to prevent man-in-the-middle attacks. rfc6066, section 3: 3. Server Name Indication TLS does not provide a mechanism for a client to tell a server the name of the server it is contacting. It may be desirable for clients to provide this information to facilitate secure connections to servers that host multiple 'virtual' servers at a single underlying network address. It looks blatantly obvious to me that rfc2818: "check the hostname of the server agains the server's identity as presented in the server's Certifcate messag" and rfc6066: "a mechanism for a client to tell a server the name of the server it is contacting" refers to the VERY SAME THING, and that the check urged by rfc2818 section 3.1 is the reason why the server responding with the _wrong_ certificate is a problem. > > In protocol version SSLv3->TLSv1.2, encryption keys are only established > >> *AFTER* successful authentication of the server through its server >> certificate. So it was obviously impossible to encrypt the information >> whose only purpose it was to allow the server to decide *which* TLS Server >> certificate to use for authentication (hen-and-egg). > > This isn't really correct: the mechanism for encrypting SNI itself would > actually work fine in previous versions of TLS as well. Actually, no, it will not work at all in TLSv1.2 (this would not be TLSv1.2 anymore, or an entirely different TLS extension) My server-side implementation of TLS extension SNI is entirely outside of the TLS protocol stack. My middleware selects the Server certificate, and my middleware also provides the convenience function for rfc2818 section 3.1 server endpoint identification as well as the client-side SSL session cache management, because you essentially can not do this within TLS, and rfc5246 even clearly says, your implementatin shouldn't (acutally it is pretty close to a TLS must not, rfc5246, top of page 5): The TLS standard, however, does not specify how protocols add security with TLS; the decisions on how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left to the judgment of the designers and implementors of protocols that run on top of TLS. -Martin From nobody Wed Oct 17 19:26:20 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C32130E53 for ; Wed, 17 Oct 2018 19:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HReYKEIMNxJ7 for ; Wed, 17 Oct 2018 19:26:17 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E238130E57 for ; Wed, 17 Oct 2018 19:26:17 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id j17-v6so26246613lja.1 for ; Wed, 17 Oct 2018 19:26:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WVyTTffKNYWVThhuB0P0W6IBz5zazmQ/xXAXRyP5CsU=; b=jNfb95Uv+O6VphFktcZWiA43pK9Ri5jZ05aALvXBYYUlMxwGPoDaXT3gbwfDJ0ozEG aBL/RUE1cTi/oudEgQCybsiJ7jte4UOfN4o0mau0Knm4SX3MJQsaRVtWil7s6r3f7vl1 CebBWCTWDm1CFaoy/Whh4zKxs2ziyJbMzrLoGGW3jnD5I8nH7sWcx7RDclwmdkxyyQ5i X3xKv1p5RdRfbDpaM+Pw0CrrHehHCQgfn0b5X+1LbDmivRs2mxoM38k4nknce2hyZs7w GxBLIBtrhrs0Isj5FnWyYfnuQVVyOdgpL0qmM75LINQVW5akrEl3PqOO0dLW3xpjgggl McPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WVyTTffKNYWVThhuB0P0W6IBz5zazmQ/xXAXRyP5CsU=; b=BdpOOsqLJHghc8QA9QKSSP1HFMw/SAQZfHLmGMwOr3nRRAURdj0Bsf6Q31jLAMDBYM R5L/H4xpWOd5SraSf48smLhuRHzEud0GccrS5f60+moXf1lGx//PorbNaWbCUBEYCD1N 30wzCIDlikEkhlOIwW2L581erRDMng3xArRszrldyE7veuBPg/9J0rxHqgbokVTSm8w4 23FwppuDb/ltHGBI/oTTZtCxqTw2WNohBzufBttNyUDT2uClp+54raB7+SkzHXmKlj/x vuFPvMLGMn7GP/Jpz1Difdg+iKBKP3jRsXcxyuRX301DKxlONEmvl+dzqrkgsXC+RmHB yIFg== X-Gm-Message-State: ABuFfohwK90yeF5hqFZXnK1zgaBnPgMwbPkr3euAvleAytJdGkd5VgTl e/Cd+XwzDjaJF6IfKXP6Ncsi+HKL56bHvJqy4cWHhHC0tqA= X-Google-Smtp-Source: ACcGV63FtqJXLc231K2KtyW9jiuuF3XLVCyWdJk7xOO/nROUHC5ogTNBH4c+f7AtWvLA9AS+qqNX7K3CvMH6tl3Oi1Y= X-Received: by 2002:a2e:7017:: with SMTP id l23-v6mr13771346ljc.160.1539829575237; Wed, 17 Oct 2018 19:26:15 -0700 (PDT) MIME-Version: 1.0 References: <9DE64F7F-4740-4410-A004-373D8919920B@sn3rd.com> <20181017170236.DA9D1404C@ld9781.wdf.sap.corp> <20181017234110.39D36404C@ld9781.wdf.sap.corp> In-Reply-To: <20181017234110.39D36404C@ld9781.wdf.sap.corp> From: Eric Rescorla Date: Wed, 17 Oct 2018 19:25:38 -0700 Message-ID: To: mrex@sap.com Cc: Sean Turner , "" Content-Type: multipart/alternative; boundary="000000000000d8d391057877826e" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-sni-encryption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 02:26:20 -0000 --000000000000d8d391057877826e Content-Type: text/plain; charset="UTF-8" On Wed, Oct 17, 2018 at 4:41 PM Martin Rex wrote: > Eric Rescorla wrote: > > Martin Rex wrote: > > > > > Sean Turner wrote: > > > > > > > > This is the working group last call for the > > > > "Issues and Requirements for SNI Encryption in TLS" > > > > draft available at > > > > http://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/. > > > > Please review the document and send your comments to the list > > > > by 2359 UTC on 31 October 2018. > > > > > > > > > I think the idea of encrypted SNI is inherently flawed in its concept. > > > > > > > It's pretty late to raise this point > > Nope, I've raised this *EVERY* time on the list when the dead horse was > newly beaten. > And there have been multiple consensus calls to the contrary, so this is just re-raising a decided issue. >> As it is, there are a number of servers which desperately require > >> the presence of TLS extension SNI, or will fail TLS handshakes either > >> by choking and dropping connections (Microsoft IIS 8.5+) or by > >> very unhelpful alerts (several others), and also HTTP/2.0 requires > >> unconditional cleartext presence of TLS extension SNI. Any kind of > >> heuristics-based approach for clients to guess whether or not to > >> send TLS extension SNI is flawed from the start. If a network > >> middlebox can make a client present a cleartext TLS extension SNI > >> by refusing connections without cleartext TLS extension SNI, > >> the entire effort becomes pretty useless. > > > > Yes, clients must not fall back to cleartext SNI in this case. > > Please give a clear deterministic algorithm how a client can > tell apart a server that requires cleartext SNI from a server > that does not want cleartext SNI. > This isn't really the relevant question, as there are many servers now which do not require SNI. The relevant question is how a client can be made aware that a server does support ESNI and can have high confidence that it will accept it. Such an algorithm is provided in: https://tools.ietf.org/html/draft-ietf-tls-esni-01#section-4 Note that as explained in detail, it is not necessary that all clients send ESNI to that server. > It is necessary > > > that the client knows reliably that a hostname must not be sent > > > in the clear, including when the connection fails for unknown reasons, > > > and only a new URI method will reliably provide such a clear > distinction. > > > > > > > I don't agree with this claim, given that we have a number of other > proposed > > mechanisms for the client to know when ESNI is allowed, including DNS. > > DNS is a non-starter for several reasons. > > Ever heard of firewalled networks, private DNS universes and HTTP CONNECT > proxies? > Yes, I've heard of all of these. They're not relevant to the question at hand. > >> By sending TLS extension SNI in the clear to a server, the client > >> tells that server: I am going to perform an rfc2818 "HTTP over TLS" > >> section 3.1 "Server Endpoint Identification" matching > > > > I don't know where you get this from, given that RFC 6066 doesn't > > even cite 2818. > > Simply to avoid a downref. I should not have to explain this to you. > > rfc2818, section 3.1: > > 3.1. Server Identity > > In general, HTTP/TLS requests are generated by dereferencing a URI. > As a consequence, the hostname for the server is known to the client. > If the hostname is available, the client MUST check it against the > server's identity as presented in the server's Certificate message, > in order to prevent man-in-the-middle attacks. > > rfc6066, section 3: > > 3. Server Name Indication > > TLS does not provide a mechanism for a client to tell a server the > name of the server it is contacting. It may be desirable for clients > to provide this information to facilitate secure connections to > servers that host multiple 'virtual' servers at a single underlying > network address. > > > It looks blatantly obvious to me that > rfc2818: "check the hostname of the server agains the server's identity > as presented in the server's Certifcate messag" > and > rfc6066: "a mechanism for a client to tell a server the name of the > server > it is contacting" > It may be obvious to you, but I don't believe it's correct. For instance, the server might be using some form of certificates other than X.509. > In protocol version SSLv3->TLSv1.2, encryption keys are only established > > > >> *AFTER* successful authentication of the server through its server > >> certificate. So it was obviously impossible to encrypt the information > >> whose only purpose it was to allow the server to decide *which* TLS > Server > >> certificate to use for authentication (hen-and-egg). > > > > This isn't really correct: the mechanism for encrypting SNI itself would > > actually work fine in previous versions of TLS as well. > > Actually, no, it will not work at all in TLSv1.2 > (this would not be TLSv1.2 anymore, or an entirely different TLS extension) > > My server-side implementation of TLS extension SNI is entirely outside > of the TLS protocol stack. This is actually quite compatible with the encrypted SNI mechanism specified in draft-ietf-tls-esni, because it was designed to work with split architectures. -Ekr --000000000000d8d391057877826e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Oct 17, 2018 at 4:41 PM Martin Rex <= mrex@sap.com> wrote:
Eric Rescorla <ekr@rtfm.com> wrote:
> Martin Rex <mrex@= sap.com> wrote:
>
> > Sean Turner <sean@sn3rd.com> wrote:
> > >
> > > This is the working group last call for the
> > > "Issues and Requirements for SNI Encryption in TLS"= ;
> > > draft available at
> > > http://datatracker.ietf= .org/doc/draft-ietf-tls-sni-encryption/.
> > > Please review the document and send your comments to the lis= t
> > > by 2359 UTC on 31 October 2018.
> >
> >
> > I think the idea of encrypted SNI is inherently flawed in its con= cept.
> >
>
> It's pretty late to raise this point

Nope, I've raised this *EVERY* time on the list when the dead horse was=
newly beaten.

And there have been multi= ple consensus calls to the contrary, so this
is just re-raising a= decided issue.


>> As it is, there are a number of servers which desperately require<= br> >> the presence of TLS extension SNI, or will fail TLS handshakes eit= her
>> by choking and dropping connections (Microsoft IIS 8.5+) or by
>> very unhelpful alerts (several others), and also HTTP/2.0 requires=
>> unconditional cleartext presence of TLS extension SNI.=C2=A0 Any k= ind of
>> heuristics-based approach for clients to guess whether or not to >> send TLS extension SNI is flawed from the start.=C2=A0 If a networ= k
>> middlebox can make a client present a cleartext TLS extension SNI<= br> >> by refusing connections without cleartext TLS extension SNI,
>> the entire effort becomes pretty useless.
>
> Yes, clients must not fall back to cleartext SNI in this case.

Please give a clear deterministic algorithm how a client can
tell apart a server that requires cleartext SNI from a server
that does not want cleartext SNI.

This = isn't really the relevant question, as there are many servers
now which do not require SNI.

The relevant questi= on is how a client can be made aware that
a server does support E= SNI and can have high confidence that
it will accept it. Such an = algorithm is provided in:

Note that as explained in = detail, it is not necessary that all clients
send ESNI to that se= rver.





>=C2=A0 =C2=A0It is necessary
> > that the client knows reliably that a hostname must not be sent > > in the clear, including when the connection fails for unknown rea= sons,
> > and only a new URI method will reliably provide such a clear dist= inction.
> >
>
> I don't agree with this claim, given that we have a number of othe= r proposed
> mechanisms for the client to know when ESNI is allowed, including DNS.=

DNS is a non-starter for several reasons.

Ever heard of firewalled networks, private DNS universes and HTTP CONNECT proxies?

Yes, I've heard of all of = these. They're not relevant to the question at hand.


=C2=A0 >> By sending TLS extension SNI in the clear to a server, the client<= br> >> tells that server:=C2=A0 I am going to perform an rfc2818 "HT= TP over TLS"
>> section 3.1 "Server Endpoint Identification" matching >
> I don't know where you get this from, given that RFC 6066 doesn= 9;t
> even cite 2818.

Simply to avoid a downref.=C2=A0 I should not have to explain this to you.<= br>
rfc2818, section 3.1:

=C2=A0 =C2=A03.1.=C2=A0 Server Identity

=C2=A0 =C2=A0In general, HTTP/TLS requests are generated by dereferencing a= URI.
=C2=A0 =C2=A0As a consequence, the hostname for the server is known to the = client.
=C2=A0 =C2=A0If the hostname is available, the client MUST check it against= the
=C2=A0 =C2=A0server's identity as presented in the server's Certifi= cate message,
=C2=A0 =C2=A0in order to prevent man-in-the-middle attacks.

rfc6066, section 3:

=C2=A0 =C2=A03.=C2=A0 Server Name Indication

=C2=A0 =C2=A0TLS does not provide a mechanism for a client to tell a server= the
=C2=A0 =C2=A0name of the server it is contacting.=C2=A0 It may be desirable= for clients
=C2=A0 =C2=A0to provide this information to facilitate secure connections t= o
=C2=A0 =C2=A0servers that host multiple 'virtual' servers at a sing= le underlying
=C2=A0 =C2=A0network address.


It looks blatantly obvious to me that
=C2=A0 rfc2818:=C2=A0 "check the hostname of the server agains the ser= ver's identity
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0as presented in the server&= #39;s Certifcate messag"
and
=C2=A0 rfc6066:=C2=A0 "a mechanism for a client to tell a server the n= ame of the server
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0it is contacting"
<= /blockquote>

It may be obvious to you, but I don't b= elieve it's correct. For instance,
the server might be using = some form of certificates other than X.509.

> In pro= tocol version SSLv3->TLSv1.2, encryption keys are only established
>
>> *AFTER* successful authentication of the server through its server=
>> certificate. So it was obviously impossible to encrypt the informa= tion
>> whose only purpose it was to allow the server to decide *which* TL= S Server
>> certificate to use for authentication (hen-and-egg).
>
> This isn't really correct: the mechanism for encrypting SNI itself= would
> actually work fine in previous versions of TLS as well.

Actually, no, it will not work at all in TLSv1.2
(this would not be TLSv1.2 anymore, or an entirely different TLS extension)=

My server-side implementation of TLS extension SNI is entirely outside
of the TLS protocol stack.

This is actually= quite compatible with the encrypted SNI mechanism
specified in d= raft-ietf-tls-esni, because it was designed to work
with split ar= chitectures.

-Ekr

--000000000000d8d391057877826e-- From nobody Wed Oct 17 20:09:15 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0AC127148 for ; Wed, 17 Oct 2018 20:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6_Dfp07o3Zhq for ; Wed, 17 Oct 2018 20:09:12 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [198.0.208.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2801120072 for ; Wed, 17 Oct 2018 20:09:11 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 264F533D2CE; Thu, 18 Oct 2018 03:09:11 +0000 (UTC) Sender: geoffk@localhost.localdomain To: mrex@sap.com Cc: Sean Turner , tls@ietf.org References: <9DE64F7F-4740-4410-A004-373D8919920B@sn3rd.com> <20181017170236.DA9D1404C@ld9781.wdf.sap.corp> From: Geoffrey Keating Date: 17 Oct 2018 20:09:11 -0700 In-Reply-To: <20181017170236.DA9D1404C@ld9781.wdf.sap.corp> Message-ID: Lines: 29 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-sni-encryption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 03:09:14 -0000 mrex@sap.com (Martin Rex) writes: > If anyone really thinks that there should be a scheme where a > server's hostname is no longer transfered in a cleartext (including > TLS extension SNI), then first of all a *NEW* distinct URI method > should be defined for that purpose, e.g. "httph://" as a reliable > indicator to the client processing this URI, that the hostname from > this URI is not supposed to be sent over the wire in the clear > *anywhere*. Although I can see how this, or some other mechanism, might be helpful, I don't agree it has to happen *first*. Why can we not start by providing an ESNI mechanism, and then later standardize a mechanism to require it for particular hostnames? A limited-purpose client can just require TLS 1.3 and ESNI for all connections, so such a mechanism would not be required for that client. In the future TLS 1.3 and ESNI deployment may be sufficiently widespread that all clients could require them, making the mechanism unnecessary. Even if ESNI is opportunistic and so subject to active attacks, that still eliminates passive network sniffing. Even an active attack would not (I think) lead to a successful connection, because of the TLS anti-downgrade features, with consequences including user-visible error messages or the device deciding the network is non-functional and ceasing to use it, so although some hostnames may be revealed, the user or device may stop before revealing all of them. So ESNI is still useful even if not mandatory. From nobody Thu Oct 18 08:17:11 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC83E12D4E8 for ; Thu, 18 Oct 2018 08:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bamsoftware.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKDlcJdNmPdA for ; Thu, 18 Oct 2018 08:17:08 -0700 (PDT) Received: from melchior.bamsoftware.com (melchior.bamsoftware.com [69.164.193.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F32AC12426A for ; Thu, 18 Oct 2018 08:17:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bamsoftware.com; s=mail; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:To:From:Date:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=8Yo32y/Nm5WW3mql5+m53okImaMwzQiJCb/zpOYNOpY=; b=r6up9dLl84zmf7wG1g9rkJmT07 5J37dOK54o9rviljxTfmYeY6fNAxFymF8YPYOyMyo7/6X6Zr7XVIItrbipmJfOCqD9pqEblfw1ZJG /rnMajazH1HJ9zmoQBiPJ530klfJjtQCPAwWmjhiqQzQPWOgiTE83IV65jx63ozLl5Fg=; Date: Thu, 18 Oct 2018 09:16:57 -0600 From: David Fifield To: tls@ietf.org Message-ID: <20181018151657.tha6mkzytmhml52m@bamsoftware.com> References: <9DE64F7F-4740-4410-A004-373D8919920B@sn3rd.com> <20181017170236.DA9D1404C@ld9781.wdf.sap.corp> <20181017234110.39D36404C@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20180716 Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-sni-encryption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 15:17:10 -0000 On Wed, Oct 17, 2018 at 07:25:38PM -0700, Eric Rescorla wrote: > >> As it is, there are a number of servers which desperately require > >> the presence of TLS extension SNI, or will fail TLS handshakes either > >> by choking and dropping connections (Microsoft IIS 8.5+) or by > >> very unhelpful alerts (several others), and also HTTP/2.0 requires > >> unconditional cleartext presence of TLS extension SNI.  Any kind of > >> heuristics-based approach for clients to guess whether or not to > >> send TLS extension SNI is flawed from the start.  If a network > >> middlebox can make a client present a cleartext TLS extension SNI > >> by refusing connections without cleartext TLS extension SNI, > >> the entire effort becomes pretty useless. > > > > Yes, clients must not fall back to cleartext SNI in this case. > > Please give a clear deterministic algorithm how a client can > tell apart a server that requires cleartext SNI from a server > that does not want cleartext SNI. > > > This isn't really the relevant question, as there are many servers > now which do not require SNI. > > The relevant question is how a client can be made aware that > a server does support ESNI and can have high confidence that > it will accept it. Such an algorithm is provided in: > https://tools.ietf.org/html/draft-ietf-tls-esni-01#section-4 > > Note that as explained in detail, it is not necessary that all clients > send ESNI to that server. Right -- it's not a matter of a server requiring or not requiring ESNI. The way I understand it, a server that supports ESNI merely affords clients an opportunity to better protect themselves -- it is still the client's responsibility to resist downgrades, and to somehow discover (through DNS or otherwise) that the server supports ESNI in the first place. I imagine that most servers that support ESNI will continue to simultaneously support plaintext SNI connections. From nobody Thu Oct 18 08:29:26 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC471277C8 for ; Thu, 18 Oct 2018 08:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.766 X-Spam-Level: X-Spam-Status: No, score=-0.766 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHDPsuktILNa for ; Thu, 18 Oct 2018 08:29:23 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAAD312426A for ; Thu, 18 Oct 2018 08:29:23 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.23/8.16.0.23) with SMTP id w9IFHOWr022881; Thu, 18 Oct 2018 16:29:23 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=HGh4IUnctMRLCSTntUNzCSxyeirpU2KMvIeUv7Ud8mI=; b=hpjFRE/Oembi5kOaptv694Fvi+0kzlioe6UNmiHiGCNj9MRjuCaE/zkGWUniQ0QKtN59 FyCb/spg0BgnG5unbHfxRDcKKrkbtWIa4H2cGcL9DOYaMlGNmpPRY0WUJnuZ8+2Bv4Wg YdxNWI0/pCeK2ebhZQmogkDpNWc9HlcnFMdCbOocYHhM1SEXU2xkkPUSoVSNGQ+8sjlr k/G0GTeSL5vxqXKwL44N8t6XMPlRWzzRMpstT9I+4A2SMxXCBFlBrHf1mpP2TcsiACoB Fx0ll7nPmIu0skcPQURZ0amazO7mwlyHNNpkAcWZJkV6zljWqKwZoxDLAByaw/K023AB dw== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050093.ppops.net-00190b01. with ESMTP id 2n6nuc10tq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Oct 2018 16:29:23 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w9IFJhHM020394; Thu, 18 Oct 2018 11:29:21 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2n3c1ve7xe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 18 Oct 2018 11:29:21 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 18 Oct 2018 11:29:20 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1365.000; Thu, 18 Oct 2018 11:29:20 -0400 From: "Salz, Rich" To: "mrex@sap.com" , Eric Rescorla CC: "" Thread-Topic: [TLS] WGLC for draft-ietf-tls-sni-encryption Thread-Index: AQHUZaGnLV3m5GDqQUqyWgwxns4AyaUj7jIAgABWIQCAABk7AIAAxduA Date: Thu, 18 Oct 2018 15:29:20 +0000 Message-ID: References: <9DE64F7F-4740-4410-A004-373D8919920B@sn3rd.com> <20181017170236.DA9D1404C@ld9781.wdf.sap.corp> <20181017234110.39D36404C@ld9781.wdf.sap.corp> In-Reply-To: <20181017234110.39D36404C@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.12.0.181014 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.153] Content-Type: text/plain; charset="utf-8" Content-ID: <302D17F0517A3F44B83A2028F222A1AA@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-18_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=925 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810180131 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-18_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=922 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810180131 Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-sni-encryption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 15:29:25 -0000 PiAgICBOb3BlLCBJJ3ZlIHJhaXNlZCB0aGlzICpFVkVSWSogdGltZSBvbiB0aGUgbGlzdCB3aGVu IHRoZSBkZWFkIGhvcnNlIHdhcw0KICAgIG5ld2x5IGJlYXRlbi4NCiAgDQpBbmQgeW91IHdlcmUg aW4gdGhlIG1pbm9yaXR5LCB0aGUgV0cgY29uc2Vuc3VzIGhhcyBjbGVhcmx5IGJlZW4gdG8gd29y ayBvbiB0aGlzLCBkZXNwaXRlIHlvdXIgb2JqZWN0aW9ucy4NCg0K From nobody Thu Oct 18 10:34:18 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82004130E44 for ; Thu, 18 Oct 2018 10:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxyaRqEa_0VK for ; Thu, 18 Oct 2018 10:34:14 -0700 (PDT) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52CEB130E14 for ; Thu, 18 Oct 2018 10:34:14 -0700 (PDT) Received: by mail-qt1-x829.google.com with SMTP id b4-v6so35174895qtc.7 for ; Thu, 18 Oct 2018 10:34:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=4mK1B/2XwlBR/6iW/H+6XHB1J62u8fxBq5L7SFJhVoo=; b=aGTAmSXHGh24LraOpABWkCX4JYa/qLH/U2dIkV26mHJyDWnFSqguuZvh14Z7IAGRlk yHJkIvp81eA1UYZLt2sGeX6OwZY+sRV0xQj1Ak4RpdLIWh09nGbZBQA2KK0H+SkYiBdl JJsmvN9xpRwJX+0bMk68JX3Cx0NPTYTtWS4qQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=4mK1B/2XwlBR/6iW/H+6XHB1J62u8fxBq5L7SFJhVoo=; b=BnLnNjpSMHcOfJ7Q4K3vPdY7OGeZP1ntoFODiR95u9ioUbRmpDDue82EHWoV2yO4xg F2XY1YElLdZviO1WdvjYBSuiso0TCVNrAvqXC98ZoQUYYGburq1EOMDfl3kjJw3miNdO ncw/CDiERrtxQU7sH8/SsV+omEMBvwSKk8ydFv2jEsfeIiGf63D4TWUvlooKMJp7X12J 7lG5a3Dno3rXx460garSRl6dXAzM00ptfnRqmC1DZlNRCtyhCNeex26xCU7VsIDM7XHO G0t7ozeCllyu1beetcybzlGhe/pnwRKnYDxfW4kbFPojQkWQ1GY2GmCTPnxUG2D2Qk9r ckhg== X-Gm-Message-State: ABuFfoiBR+tEEd5GjuaJKKKDnnhGvYzVjUA6LSa01X2sSi9CDLqr6uKt qGMr1+pANM0DpbjXZ8GkGXRsp+i9WTQ= X-Google-Smtp-Source: ACcGV62Vf5a2p7E4Q3W90Tc5keY1dX6geBfAhryXFQkEQawhvbGUCaPZfmnz5BRLvQLoWxQVHk8HmQ== X-Received: by 2002:a0c:95e6:: with SMTP id t35mr31401834qvt.163.1539884053136; Thu, 18 Oct 2018 10:34:13 -0700 (PDT) Received: from [172.16.0.18] ([96.231.224.191]) by smtp.gmail.com with ESMTPSA id e24-v6sm14348023qtc.78.2018.10.18.10.34.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Oct 2018 10:34:12 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 18 Oct 2018 13:34:09 -0400 References: <731A3824-C45D-416B-AACD-B1AC4D8DEFD3@sn3rd.com> To: tls@ietf.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [TLS] TLS@IETF103: Agenda Topics X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 17:34:17 -0000 This is yet another reminder to submit agenda topics for IETF 103. spt > On Oct 10, 2018, at 18:09, Sean Turner wrote: >=20 > This is a reminder to submit agenda topics for IETF 103. We currently = have two slots scheduled [0] so if you are requesting time please have a = look at the agenda and indicate which day works best. >=20 > spt >=20 > [0] https://datatracker.ietf.org/meeting/agenda/ >=20 >> On Sep 20, 2018, at 08:31, Sean Turner wrote: >>=20 >> The TLS WG will be meeting @ IETF 103 in Bangkok. To help the chairs = get a better handle on how much time we will need for our session, = please send in your agenda requests to tls-chairs@ietf.org. Along with = your request please provide an estimate for how much time you will need. >>=20 >> Cheers, >>=20 >> CJS >=20 From nobody Thu Oct 18 13:13:04 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207E5130DE4 for ; Thu, 18 Oct 2018 13:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.766 X-Spam-Level: X-Spam-Status: No, score=-0.766 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SCcBBzHvuwO for ; Thu, 18 Oct 2018 13:13:01 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B472C1286E3 for ; Thu, 18 Oct 2018 13:13:01 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.23/8.16.0.23) with SMTP id w9IK7eUV028683; Thu, 18 Oct 2018 21:13:01 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=+oTDJKHwkcAlrf77xZfB1/yNdxE/A8+AUVRAozkkdI0=; b=j/F+gb8y0XwE8vA59lncxX9v8MfP1OuEIaHb3/R1NwtI/V8ClgkdbKw0rWZtDYS65Izt 1ZkWuWnJIKRzkpnxLCX8+OSP3W0xFFM0O0qXtF6rG7o0IY0J6mp1KNXCMrmjSGLzod1P OqdA6r58GMwL19L9Tq7WUgRrfqSAYAAwdMeyb9hj+QLFNLfSpcSMTkMeNBmvkN2Qi715 RQkoLqJIfK17SRGlErDd1ztdftEnNflE6/R6YjCOOMTQBg1PcPAj1IDjHlPr10MHxLJH zP6JN02gB/3v5puvF6hOQ0v7hPaB4bYoos2tz9Cj09v9gfmr5SwydLXqLFVeDvVI9Xq6 DA== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2n6nuc1pcm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Oct 2018 21:13:01 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w9IK4oLE001924; Thu, 18 Oct 2018 16:13:00 -0400 Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint3.akamai.com with ESMTP id 2n3c1x1112-1; Thu, 18 Oct 2018 16:13:00 -0400 Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id 1A4CE80D1A; Thu, 18 Oct 2018 20:13:00 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1gDEfD-0006ni-1W; Thu, 18 Oct 2018 15:12:59 -0500 Date: Thu, 18 Oct 2018 15:12:58 -0500 From: Benjamin Kaduk To: Eric Rescorla Cc: "" Message-ID: <20181018201258.GA4141@akamai.com> References: <875zy1czbd.fsf@fifthhorseman.net> <20181017011515.GL7773@akamai.com> <20181017144025.GN7773@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-18_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810180168 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-18_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810180169 Archived-At: Subject: Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 20:13:03 -0000 On Wed, Oct 17, 2018 at 02:48:47PM -0700, Eric Rescorla wrote: > On Wed, Oct 17, 2018 at 7:40 AM Benjamin Kaduk wrote: > > > On Wed, Oct 17, 2018 at 06:18:27AM -0700, Eric Rescorla wrote: > > > I'm responding to Ben here, because I think it's worth adding some > > clarity. > > > However, I want to flag that I'm going to be rather short on time for the > > > next > > > few week and not able to spend a lot of time replying to traffic on this > > > topic. Even more than usual, non-response to some point does not > > > necessarily indicate agreement. > > > > > > On Tue, Oct 16, 2018 at 6:15 PM Benjamin Kaduk > > wrote: > > > > > > > (1) provides a channel for DANE records that is reliable in the > > absence of > > > > an attack > > > > > > > > > > I think this alone would be worthwhile -- and is the purpose I have > > always > > > had > > > in mind for the draft. > > > > It's interesting to hear that, as I seem to recall a lot of discussion > > about how a security mechanism that folds in the presence of an attack > > ... isn't really a security mechanism. > > > > So while I could concoct a few scenarios in which just (1) would be > > *useful*, the main one that comes to mind isn't really a security > > mechanism, but would rather be part of a reporting mechanism for seeing > > what kind of DANE penetration is possible. Well, and I guess any case > > where the client has some other reason to expect to see this extension > > and choke if it's absent, such as a "greenfield" case or > > application-level pinning. So I'm curious what kind of use case(s) you had > > in mind for just the transport aspect. > > > > Given that you just described at least two use cases, I feel like you've > answered > your own question here. Hardly. In particular, I was asking what *you* had in mind -- my listing was intended to be more of a "straw man" sort of thing. -Ben From nobody Thu Oct 18 14:46:32 2018 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C14D712F1AC; Thu, 18 Oct 2018 14:46:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <153989919075.22172.15409436335061812040@ietfa.amsl.com> Date: Thu, 18 Oct 2018 14:46:30 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-exported-authenticator-08.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 21:46:31 -0000 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 : Exported Authenticators in TLS Author : Nick Sullivan Filename : draft-ietf-tls-exported-authenticator-08.txt Pages : 12 Date : 2018-10-18 Abstract: This document describes a mechanism in Transport Layer Security (TLS) to provide an exportable proof of ownership of a certificate that can be transmitted out of band and verified by the other party. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-exported-authenticator-08 https://datatracker.ietf.org/doc/html/draft-ietf-tls-exported-authenticator-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-exported-authenticator-08 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/ From nobody Thu Oct 18 14:55:25 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2EB130E22 for ; Thu, 18 Oct 2018 14:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.064 X-Spam-Level: X-Spam-Status: No, score=-2.064 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2uQzfAvrMva for ; Thu, 18 Oct 2018 14:55:21 -0700 (PDT) Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5732112F1AC for ; Thu, 18 Oct 2018 14:55:20 -0700 (PDT) Received: by mail-oi1-x234.google.com with SMTP id p125-v6so25289754oic.3 for ; Thu, 18 Oct 2018 14:55:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=WG3u872cUJIW1u8ZdqwZIKCUtRUEmE9uznTt9E3Ql4Y=; b=Y3p+4agR6vh84FMhygMyRpoZQZd+yNtqhaSFYXDfpOvNK9CUzLmd4KdaA5w3eYODuY gDs5cxN4Stl3mLtsbWER7znGOKUhhZXQafvsCkc8LaT5posiTQA1M0MxZezrpvf7BH+w B4gwwGKPIcFCImE1ER9yreebsI/PReqY7h7Ac= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=WG3u872cUJIW1u8ZdqwZIKCUtRUEmE9uznTt9E3Ql4Y=; b=ptGrCRGxCdpdIh/Z3+ijCNPj96036IUBfsZyBUC5rMAlK+vZZhc1zFMEF2r2Xgd3ax 3sH6oeO5DXfopyW392ByteTchkDozndxPgqhmKB5LSopiuIBf683mUwpyNLw6Ptqn+yi +hCCiPqlcKKosFQCS8n7lpDuJ5ixKXTOdnSDJ5LlGeoi6O4xhQ+Q3hvPkxYcM0gXPput /1NwoItFYPY0ogq+Kj+ujLW4mC2zNLJe3N4SZ8pdUw5B78sARCMDM1u+VhoWeBeFI/Es qnbIL/CRvfHSCPmx9DsOYN7ddyvAhI4Ib2WCY2HEGifQ2HzW4KtuQv1KCTHh6FMwaE+5 izxw== X-Gm-Message-State: ABuFfoiy1brwmUzIE17cIf7niTKo8b/RZTd/R3AnYJHGl9fT/xjo5M/8 nodt6+Wh5+L4uhSxxVqt60c0lHnznpjx1R3jbQeQs8kDCvY= X-Google-Smtp-Source: ACcGV62j6/jH/3WeOGi0RQ+JcRN7XBLyAx7l6FK9d+eH63qrDyNnmT5eu32I9DKK9OnG6Zg7HZDQ2WI7NH68pFp57Bk= X-Received: by 2002:aca:ce07:: with SMTP id e7-v6mr18262208oig.54.1539899719277; Thu, 18 Oct 2018 14:55:19 -0700 (PDT) MIME-Version: 1.0 References: <153989919095.22172.10646656164086304977.idtracker@ietfa.amsl.com> In-Reply-To: <153989919095.22172.10646656164086304977.idtracker@ietfa.amsl.com> From: Nick Sullivan Date: Thu, 18 Oct 2018 14:55:07 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c20834057887d7ee" Archived-At: Subject: [TLS] Fwd: New Version Notification for draft-ietf-tls-exported-authenticator-08.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 21:55:24 -0000 --000000000000c20834057887d7ee Content-Type: text/plain; charset="UTF-8" I've posted draft 08 of Exported Authenticators. It contains a few minor changes: - an updated reference to RFC 8443 - an updated IANA considerations section - a text change to require CRCs to be unique within a connection (requested at IETF 102 by Jonathan Hoyland) - minor text fixes At this point, I'd like the chairs to consider starting a second last call for this document. Nick Sullivan ---------- Forwarded message --------- From: Date: Thu, Oct 18, 2018 at 2:46 PM Subject: New Version Notification for draft-ietf-tls-exported-authenticator-08.txt To: Nick Sullivan A new version of I-D, draft-ietf-tls-exported-authenticator-08.txt has been successfully submitted by Nick Sullivan and posted to the IETF repository. Name: draft-ietf-tls-exported-authenticator Revision: 08 Title: Exported Authenticators in TLS Document date: 2018-10-18 Group: tls Pages: 12 URL: https://www.ietf.org/internet-drafts/draft-ietf-tls-exported-authenticator-08.txt Status: https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ Htmlized: https://tools.ietf.org/html/draft-ietf-tls-exported-authenticator-08 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-tls-exported-authenticator Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-exported-authenticator-08 Abstract: This document describes a mechanism in Transport Layer Security (TLS) to provide an exportable proof of ownership of a certificate that can be transmitted out of band and verified by the other party. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --000000000000c20834057887d7ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've posted draft 08 of Exported Authenticators. It co= ntains a few minor changes:
- an updated reference to RFC 8443
- an updated IANA considerations section
- a text change to req= uire CRCs to be unique within a connection (requested at IETF 102 by Jonath= an Hoyland)
- minor text fixes

At this point, I'd like= the chairs to consider starting a second last call for this document.
<= br>Nick Sullivan

-------= --- Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: Thu, Oct 18, 2018 = at 2:46 PM
Subject: New Version Notification for draft-ietf-tls-exported= -authenticator-08.txt
To: Nick Sullivan <nick@cloudflare.com>



A new version of I-D, draft-ietf-tls-exported-authenticator-08.txt
has been successfully submitted by Nick Sullivan and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-tls-exported-authe= nticator
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A008
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Exported Authenticators in TLS
Document date:=C2=A0 2018-10-18
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 tls
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 12
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-= tls-exported-authenticator-08.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authen= ticator/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-ietf-tls-exported-authenticator-08
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-tls-exported-a= uthenticator
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-ex= ported-authenticator-08

Abstract:
=C2=A0 =C2=A0This document describes a mechanism in Transport Layer Securit= y (TLS)
=C2=A0 =C2=A0to provide an exportable proof of ownership of a certificate t= hat can
=C2=A0 =C2=A0be transmitted out of band and verified by the other party.



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

The IETF Secretariat

--000000000000c20834057887d7ee-- From nobody Thu Oct 18 16:59:11 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C73B9130E69 for ; Thu, 18 Oct 2018 16:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEr0o0daLZm4 for ; Thu, 18 Oct 2018 16:59:07 -0700 (PDT) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89BD0130E2A for ; Thu, 18 Oct 2018 16:59:07 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id u20-v6so5404787qkk.9 for ; Thu, 18 Oct 2018 16:59:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wxzJMN2HI5DXgAG7B4yMQmHbbzRA7Ooe6ZfOHGYvKTA=; b=juSMxOrw8JeCvPWuIgbDkspiOUv7BIW50bcGcl1lIimwk+smHrTS6FdeutQGlKP4h0 Gqesr5v18NGorIjT6857poHor87UU+T2ZJfeCYufAD4Vjtv8hj9Grl1BNcVwbrkS8Qg7 UYgwoAx69429Ah1fnyfVj4sZPCtli4a/gP1oY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wxzJMN2HI5DXgAG7B4yMQmHbbzRA7Ooe6ZfOHGYvKTA=; b=IvpJrBaxhTXSO6DXgRllum1GHHlDq/Cy6Rt0cyBmTHmFicfSnOIrhtmSLlHnckj0HR zVVDmbIcJ7yCv2Elrt/NKE+BHDtk9IEAzvQPnIAFAPnFctDN52kJ+usnz1ElXv8j0IBG hiMZQ/cTeDY9bMSwBNC4xy9NZa+CHmCZJ0XH5crBHApZ29j+/4Dh/yioaJN6PXN9wexX CmDQzrWsiPiWZkDc2jjwx/ZoyWinEJFHtBuHywh4HDSZMVee7Q4BtWa68vLC1izSPX6M AsfHUoIa9MdBOai5dwJx33dRucqhKLgk81sXZdh8VFBp8YS0AioTVwX3IR5xZxCdkPeS cFqQ== X-Gm-Message-State: ABuFfoh8iCapoJkBzctS/+wO/pzSVKodWeGM8WHrsWvBZRnxa+rIyOoB OP3I+ndbAE7Y06waYwdpSAwW2g== X-Google-Smtp-Source: ACcGV621vnBR+WwWSXKA/0ywYLUP4WmJXCx7vG0nNVQEnwhG4J5DXhsI/a18zCXEofoMRUlQ9I8mXw== X-Received: by 2002:a37:3947:: with SMTP id g68-v6mr28984586qka.289.1539907146599; Thu, 18 Oct 2018 16:59:06 -0700 (PDT) Received: from [172.16.0.18] ([96.231.224.191]) by smtp.gmail.com with ESMTPSA id t128-v6sm1563960qkh.80.2018.10.18.16.59.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Oct 2018 16:59:05 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sean Turner In-Reply-To: Date: Thu, 18 Oct 2018 19:59:04 -0400 Cc: "tls@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8D2FF3FD-E2F5-4186-9952-349D5F6AE6D4@sn3rd.com> References: <153989919095.22172.10646656164086304977.idtracker@ietfa.amsl.com> To: Nick Sullivan X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [TLS] New Version Notification for draft-ietf-tls-exported-authenticator-08.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 23:59:10 -0000 Thanks Nick. We'=E2=80=99ll have a quick look and assuming (as I am) = that everything looks good we=E2=80=99ll get the WGLC started. If = anything comes up we can address it at one of our sessions in Bangkok. spt > On Oct 18, 2018, at 17:55, Nick Sullivan = wrote: >=20 > I've posted draft 08 of Exported Authenticators. It contains a few = minor changes: > - an updated reference to RFC 8443 > - an updated IANA considerations section > - a text change to require CRCs to be unique within a connection = (requested at IETF 102 by Jonathan Hoyland) > - minor text fixes >=20 > At this point, I'd like the chairs to consider starting a second last = call for this document. >=20 > Nick Sullivan >=20 > ---------- Forwarded message --------- > From: > Date: Thu, Oct 18, 2018 at 2:46 PM > Subject: New Version Notification for = draft-ietf-tls-exported-authenticator-08.txt > To: Nick Sullivan >=20 >=20 >=20 > A new version of I-D, draft-ietf-tls-exported-authenticator-08.txt > has been successfully submitted by Nick Sullivan and posted to the > IETF repository. >=20 > Name: draft-ietf-tls-exported-authenticator > Revision: 08 > Title: Exported Authenticators in TLS > Document date: 2018-10-18 > Group: tls > Pages: 12 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-tls-exported-authenticator= -08.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-tls-exported-authenticator-08 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-tls-exported-authenticato= r > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-exported-authenticator-= 08 >=20 > Abstract: > This document describes a mechanism in Transport Layer Security = (TLS) > to provide an exportable proof of ownership of a certificate that = can > be transmitted out of band and verified by the other party. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Oct 18 23:25:22 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4CB126BED for ; Thu, 18 Oct 2018 23:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNouuTF61Irc for ; Thu, 18 Oct 2018 23:25:18 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E0BB126CC7 for ; Thu, 18 Oct 2018 23:25:18 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 15CF9B8011D; Thu, 18 Oct 2018 23:24:51 -0700 (PDT) To: tim@dierks.org, ekr@rtfm.com, kaduk@mit.edu, ekr@rtfm.com, christopherwood07@gmail.com, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: dave_thompson_2@comcast.net, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20181019062451.15CF9B8011D@rfc-editor.org> Date: Thu, 18 Oct 2018 23:24:51 -0700 (PDT) Archived-At: Subject: [TLS] [Technical Errata Reported] RFC5246 (5535) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 06:25:21 -0000 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: http://www.rfc-editor.org/errata/eid5535 -------------------------------------- Type: Technical Reported by: Dave Thompson Section: 4.7 Original Text ------------- In DSA, the 20 bytes of the SHA-1 hash are run directly through the Digital Signing Algorithm with no additional hashing. ... Corrected Text -------------- In DSA, the bytes of the selected hash are run directly through the Digital Signing Algorithm with no additional hashing. ... Notes ----- In 2246 and 4346 this statement (then using the less-accurate spellings DSS and SHA) was correct because only SHA1 was used for DSA (and ECDSA, in 4492, versus SHA1+MD5 for RSA), but 5246 changed this to allow specifying one of several hashes, with selection constrained by the signature_algorithms extension (if present) or CertificateRequest field from the peer. FIPS 186 actually defines the hashing step as part of signature generation and verification, so it might be even better to make this something like "For DSA, signature generation applies the selected hash [to the contents] and then computes two values, r and s." similar to the way the preceding paragraph of 5246 "In RSA signing" differs from the 2246 and 4346 versions by no longer treating the hashing as separate, but that is a bigger change to an obsoleted document, and arguably problematic because the normative reference is FIPS 186-2; as indicated in Appendix B on page 80, 186-3 which officially allowed DSA to use FIPS 180-3 hashes (not only SHA-1) was released in draft before 5246 but not finalized until after (2006-03 to 2009-06 versus 2008-08). 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 From nobody Thu Oct 18 23:35:01 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C0B126CC7 for ; Thu, 18 Oct 2018 23:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikOpAQMd-Y5o for ; Thu, 18 Oct 2018 23:34:56 -0700 (PDT) Received: from mail-oi1-x244.google.com (mail-oi1-x244.google.com [IPv6:2607:f8b0:4864:20::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42A15126BED for ; Thu, 18 Oct 2018 23:34:56 -0700 (PDT) Received: by mail-oi1-x244.google.com with SMTP id u74-v6so25977174oia.11 for ; Thu, 18 Oct 2018 23:34:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=mhgmR7V5AUbea2xForD/1OtujHzM0vWrPnL573KQHH8=; b=sqcCgzqLSPDa4Te5CJcJhGvBasrQaaQ/YLmoLZTf49Ykw7oUwaDv6e1cQRditdgNne FqUmn0cmtH9WOLY8FaZklRRMxmDXhwavFc1TvAttjWmrC0HpuINb14avcujuWNfp37PC +Az6Y8SClO/gMzjkKcYgGZxEha+R6xp/cUDaiqAkAcFBpnJBoSsX41Jxzu4ZFL0lZJJB lpQU9buy2uaueTbmDF6ieTO1GSxazCrKXnRPXpdeBnP22grr+CKXBysVJSaqjzSYyPUS 8mgIVYsYie27iCQl4sSFgKkDiI1wTb1sJi6EXH3U0stP7Tb9KAXaft/w8wHUzUU1DEmW vWwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=mhgmR7V5AUbea2xForD/1OtujHzM0vWrPnL573KQHH8=; b=Joh6wmFElOoMClD1QxPp/WAV8KBusmzxteUT241Igfscz0lsxp73Dm05VHPzjM95PK Cz/wDJ3Yrixa5Dwg6F811MjXyhmy75bfFphdpKittooHn89H5ATIQ6vPWPFDPHs95HQm wS85NaU/8ZSjHZuf348WbZ5JeRnlRwPr6ZQR5GGU2yXVI6twHA8m6HMNzpOoo6fKxJgy LDPU4Y4MmF4PlnrvTA46gbtXUp4hIKIzWArzBAOQBSy4q/y/IXRt0CeWAixgXmMo0qCo Wrgmfl4Z5O33fPJYzkaVG8qsJLHGEu04CXtEd0Yh8FOrhj0fWhmCjP0uerSXLCn2hF3g Cdnw== X-Gm-Message-State: ABuFfoiVS/i73MiCGg92/5XZK590ziAAuzlBxQS0P1yFt11ySBZC31P+ jRaIDT/WXV8pCyB2y6BZEigXPJBxPBA99FUmIrk= X-Google-Smtp-Source: ACcGV60hWYmqClGesi13VeSJROShQvNLrEkMHfcSOJn7eSzZ1bs4u528OoNaTG37/U0b2hE6ggijez7J0U5Y205Hktg= X-Received: by 2002:aca:5452:: with SMTP id i79-v6mr18590386oib.344.1539930895469; Thu, 18 Oct 2018 23:34:55 -0700 (PDT) MIME-Version: 1.0 References: <20181019062451.15CF9B8011D@rfc-editor.org> In-Reply-To: <20181019062451.15CF9B8011D@rfc-editor.org> From: Martin Thomson Date: Fri, 19 Oct 2018 17:34:48 +1100 Message-ID: To: RFC Errata System Cc: Tim Dierks , Eric Rescorla , Benjamin Kaduk , Christopher Wood , Joseph Salowey , sean+ietf@sn3rd.com, dave_thompson_2@comcast.net, "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] [Technical Errata Reported] RFC5246 (5535) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 06:34:59 -0000 An artifact of the times more than an error methinks? The document does also say: "Currently, DSA [DSS] may only be used with SHA-1." in the context of talking about use of different hash algorithms for DSA. Good thing that we obsoleted that RFC and removed DSA, now we don't have to worry about it any more... ;) Seriously though, I don't know the process for dealing with valid criticisms of features that have been obsoleted. Hold For Document Update seems very wrong, so we can rule that out at least. On Fri, Oct 19, 2018 at 5:25 PM 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: > http://www.rfc-editor.org/errata/eid5535 > > -------------------------------------- > Type: Technical > Reported by: Dave Thompson > > Section: 4.7 > > Original Text > ------------- > In DSA, the 20 bytes of the SHA-1 hash are run directly through the > Digital Signing Algorithm with no additional hashing. ... > > Corrected Text > -------------- > In DSA, the bytes of the selected hash are run directly through the > Digital Signing Algorithm with no additional hashing. ... > > Notes > ----- > In 2246 and 4346 this statement (then using the less-accurate spellings D= SS and SHA) was correct because only SHA1 was used for DSA (and ECDSA, in 4= 492, versus SHA1+MD5 for RSA), but 5246 changed this to allow specifying on= e of several hashes, with selection constrained by the signature_algorithms= extension (if present) or CertificateRequest field from the peer. > > FIPS 186 actually defines the hashing step as part of signature generatio= n and verification, so it might be even better to make this something like = "For DSA, signature generation applies the selected hash [to the contents] = and then computes two values, r and s." similar to the way the preceding pa= ragraph of 5246 "In RSA signing" differs from the 2246 and 4346 versions by= no longer treating the hashing as separate, but that is a bigger change to= an obsoleted document, and arguably problematic because the normative refe= rence is FIPS 186-2; as indicated in Appendix B on page 80, 186-3 which off= icially allowed DSA to use FIPS 180-3 hashes (not only SHA-1) was released = in draft before 5246 but not finalized until after (2006-03 to 2009-06 vers= us 2008-08). > > 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://www.ietf.org/mailman/listinfo/tls From nobody Fri Oct 19 06:33:36 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 954C2130E70 for ; Fri, 19 Oct 2018 06:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBCKjY8Uyjxi for ; Fri, 19 Oct 2018 06:33:33 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DDDB130E0A for ; Fri, 19 Oct 2018 06:33:33 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9E072B80922; Fri, 19 Oct 2018 06:33:05 -0700 (PDT) To: turners@ieca.com, tim.polk@nist.gov, kaduk@mit.edu, ekr@rtfm.com, christopherwood07@gmail.com, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: eugene.adell@gmail.com, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20181019133305.9E072B80922@rfc-editor.org> Date: Fri, 19 Oct 2018 06:33:05 -0700 (PDT) Archived-At: Subject: [TLS] [Editorial Errata Reported] RFC6176 (5536) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 13:33:35 -0000 The following errata report has been submitted for RFC6176, "Prohibiting Secure Sockets Layer (SSL) Version 2.0". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5536 -------------------------------------- Type: Editorial Reported by: Eugene Adell Section: 1 Original Text ------------- RFC 4346 [TLS1.1], and later RFC 5246 [TLS1.2], explicitly warned implementers that the "ability to send version 2.0 CLIENT-HELLO messages will be phased out with all due haste". This document accomplishes this by updating the backward compatibility sections found in TLS [TLS1.0][TLS1.1][TLS1.2]. Corrected Text -------------- RFC 2246 [TLS1.0], and later RFC 4346 [TLS1.1], then RFC 5246 [TLS1.2] explicitly warned implementers that the "ability to send version 2.0 CLIENT-HELLO messages will be phased out with all due haste". This document accomplishes this by updating the backward compatibility sections found in TLS [TLS1.0][TLS1.1][TLS1.2]. Notes ----- The warning on the version 2.0 Client Hello is as old as the first TLS version (RFC 2246 Appendix E). That's what the authors meant and wanted to highlight by listing two of the three RFCs containing this warning. This is confirmed by their last sentence. It looks like a small mistake without concrete effects, I push this errata considering "IESG Processing of RFC Errata for the IETF Stream rule 6" 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. -------------------------------------- RFC6176 (draft-ietf-tls-ssl2-must-not-04) -------------------------------------- Title : Prohibiting Secure Sockets Layer (SSL) Version 2.0 Publication Date : March 2011 Author(s) : S. Turner, T. Polk Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Fri Oct 19 07:20:50 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5FE130F03 for ; Fri, 19 Oct 2018 07:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPie2Zv_NwR7 for ; Fri, 19 Oct 2018 07:20:46 -0700 (PDT) Received: from 4.mo173.mail-out.ovh.net (4.mo173.mail-out.ovh.net [46.105.34.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDACE130EFB for ; Fri, 19 Oct 2018 07:20:45 -0700 (PDT) Received: from player159.ha.ovh.net (unknown [10.109.146.86]) by mo173.mail-out.ovh.net (Postfix) with ESMTP id AEF5BDCAEF for ; Fri, 19 Oct 2018 16:20:43 +0200 (CEST) Received: from [192.168.0.11] (rng31-1-88-168-248-146.fbx.proxad.net [88.168.248.146]) (Authenticated sender: contact@simonbernard.eu) by player159.ha.ovh.net (Postfix) with ESMTPSA id E99844800AC; Fri, 19 Oct 2018 16:20:41 +0200 (CEST) To: Eric Rescorla Cc: "" References: <6bab54cd-e903-ac3e-a186-077458a2d652@simonbernard.eu> From: Simon Bernard Message-ID: Date: Fri, 19 Oct 2018 16:20:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------97AE8088B8CBF4796EAED926" Content-Language: en-US X-Ovh-Tracer-Id: 16733968840664168689 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrfeeigdejlecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecu Archived-At: Subject: Re: [TLS] HELLO_VERIFY_REQUEST during abbreviated handshake (session resumption) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 14:20:49 -0000 This is a multi-part message in MIME format. --------------97AE8088B8CBF4796EAED926 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thx Ekr. Here is a discussion about our concerns : https://github.com/eclipse/californium/pull/751 Le 16/10/2018 à 22:18, Eric Rescorla a écrit : > Hi Simon, > > I don't think we specified a concrete recommendation, but I think the > answer is probably no. The reason is that: > > (a) a resumed handshake is very cheap, so it's not really saving CPU > (b) the server's first flight is small in resumption, so amplification > isn't much of an issue. > > Maybe I'm missing something though. > > -Ekr > > > > > On Wed, Oct 3, 2018 at 7:05 AM Simon Bernard > wrote: > > Hi, > >     In DTLS 1.2 over UDP, I would like to know what is the > recommendation about using HELLO_VERIFY_REQUEST during an abbreviated > handshake. > >     Should we send it all the time ? or could we avoid to send it if > SESSION ID is known ? > > Thx, > > > Simon > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --------------97AE8088B8CBF4796EAED926 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Thx Ekr. Here is a discussion about our concerns : https://github.com/eclipse/californium/pull/751

Le 16/10/2018 à 22:18, Eric Rescorla a écrit :
Hi Simon,

I don't think we specified a concrete recommendation, but I think the answer is probably no. The reason is that:

(a) a resumed handshake is very cheap, so it's not really saving CPU
(b) the server's first flight is small in resumption, so amplification isn't much of an issue.

Maybe I'm missing something though.

-Ekr

 
 

On Wed, Oct 3, 2018 at 7:05 AM Simon Bernard <contact@simonbernard.eu> wrote:
Hi,

    In DTLS 1.2 over UDP, I would like to know what is the
recommendation about using HELLO_VERIFY_REQUEST during an abbreviated
handshake.

    Should we send it all the time ? or could we avoid to send it if
SESSION ID is known ?

Thx,


Simon

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--------------97AE8088B8CBF4796EAED926-- From nobody Fri Oct 19 08:00:08 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10DE8130F06 for ; Fri, 19 Oct 2018 08:00:02 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...] X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-LBekwupEgP for ; Fri, 19 Oct 2018 07:59:59 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20791130F55 for ; Fri, 19 Oct 2018 07:59:58 -0700 (PDT) X-AuditID: 12074423-45fff700000031b7-a3-5bc9f16bef7c Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 94.45.12727.C61F9CB5; Fri, 19 Oct 2018 10:59:57 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.14.7/8.9.2) with ESMTP id w9JExnQR032765; Fri, 19 Oct 2018 10:59:51 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) œby outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id w9JExgZt029540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 19 Oct 2018 10:59:45 -0400 Date: Fri, 19 Oct 2018 09:59:42 -0500 From: Benjamin Kaduk To: Martin Thomson Cc: RFC Errata System , Tim Dierks , Eric Rescorla , Christopher Wood , Joseph Salowey , sean+ietf@sn3rd.com, dave_thompson_2@comcast.net, "" Message-ID: <20181019145942.GD19309@kduck.kaduk.org> References: <20181019062451.15CF9B8011D@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCKsWRmVeSWpSXmKPExsUixG6nrpv78WS0wY3DLBbTv19js7jct4vV YsXrc+wW2zbtZ7e4duYfo0XT/q9sFpc2rGay+L1nHrvFp/NdjA6cHpMfz2H0+LVmMZvHzll3 2T2WLPnJ5NHQdowVKNHG7HF81wZ2j4MHGQM4orhsUlJzMstSi/TtErgyms7tZC64L1txc1N5 A+NO8S5GTg4JAROJJ1+6mLsYuTiEBNYwSSw/cY0NwtnIKNGy5AWUc5dJYvbd1ewgLSwCqhJr H/5mArHZBFQkGrovM4PYIgK6EovOPgCrYRbYyiQxcZptFyMHh7CArcShTcIgJi/Qtsk3HEAq hATqJD6v+w42hVdAUOLkzCcsEJ1aEjf+vWQCKWcWkJZY/o8DJMwpECjRtmMNK4gtKqAssbfv EPsERoFZSLpnIemehdC9gJF5FaNsSm6Vbm5iZk5xarJucXJiXl5qka6ZXm5miV5qSukmRnCE uCjvYHzZ532IUYCDUYmHt+DoiWgh1sSy4srcQ4ySHExKorwF6iejhfiS8lMqMxKLM+KLSnNS iw8xSnAwK4nwKpYC5XhTEiurUovyYVLSHCxK4rwTWxZHCwmkJ5akZqemFqQWwWRlODiUJHif fQBqFCxKTU+tSMvMKUFIM3FwggznARreClLDW1yQmFucmQ6RP8Woy9H29PoMZiGWvPy8VClx 3nvvgYoEQIoySvPg5oASm0T2/ppXjOJAbwnzmoKM4gEmRbhJr4CWMAEtOWF6AmRJSSJCSqqB cU70Ed4nC0WkhXLuPD+1wypd2K/o9RmODmXjR1NM/z0I+/tK/nypu133ROPHUyYem+1gWzPz S86JrXwhKU6WTDpMsw8pBs134TB64i74Z2vs+wvJfPOD5Hv87miqqCl0sS3/c6WIN1NqSQzP N/b/ln4nVledc+TZtu3o38CUiyUvtJtexWbrK7EUZyQaajEXFScCAOsQCoRHAwAA Archived-At: Subject: Re: [TLS] [Technical Errata Reported] RFC5246 (5535) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 15:00:07 -0000 It does feel like an artifact of the times, yes. So I am not sure if there is a better option than "Rejected" (or, I guess, leave in "Reported" indefinitely). -Ben On Fri, Oct 19, 2018 at 05:34:48PM +1100, Martin Thomson wrote: > An artifact of the times more than an error methinks? The document > does also say: "Currently, DSA [DSS] may only be used with SHA-1." in > the context of talking about use of different hash algorithms for DSA. > > Good thing that we obsoleted that RFC and removed DSA, now we don't > have to worry about it any more... ;) Seriously though, I don't know > the process for dealing with valid criticisms of features that have > been obsoleted. Hold For Document Update seems very wrong, so we can > rule that out at least. > > On Fri, Oct 19, 2018 at 5:25 PM 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: > > http://www.rfc-editor.org/errata/eid5535 > > > > -------------------------------------- > > Type: Technical > > Reported by: Dave Thompson > > > > Section: 4.7 > > > > Original Text > > ------------- > > In DSA, the 20 bytes of the SHA-1 hash are run directly through the > > Digital Signing Algorithm with no additional hashing. ... > > > > Corrected Text > > -------------- > > In DSA, the bytes of the selected hash are run directly through the > > Digital Signing Algorithm with no additional hashing. ... > > > > Notes > > ----- > > In 2246 and 4346 this statement (then using the less-accurate spellings DSS and SHA) was correct because only SHA1 was used for DSA (and ECDSA, in 4492, versus SHA1+MD5 for RSA), but 5246 changed this to allow specifying one of several hashes, with selection constrained by the signature_algorithms extension (if present) or CertificateRequest field from the peer. > > > > FIPS 186 actually defines the hashing step as part of signature generation and verification, so it might be even better to make this something like "For DSA, signature generation applies the selected hash [to the contents] and then computes two values, r and s." similar to the way the preceding paragraph of 5246 "In RSA signing" differs from the 2246 and 4346 versions by no longer treating the hashing as separate, but that is a bigger change to an obsoleted document, and arguably problematic because the normative reference is FIPS 186-2; as indicated in Appendix B on page 80, 186-3 which officially allowed DSA to use FIPS 180-3 hashes (not only SHA-1) was released in draft before 5246 but not finalized until after (2006-03 to 2009-06 versus 2008-08). > > > > 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://www.ietf.org/mailman/listinfo/tls From nobody Fri Oct 19 12:02:53 2018 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 225A71310D3; Fri, 19 Oct 2018 11:56:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: tls@ietf.org, kaduk@mit.edu X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153997539813.6592.14815383131750864946.idtracker@ietfa.amsl.com> Date: Fri, 19 Oct 2018 11:56:38 -0700 Archived-At: Subject: [TLS] tls - Requested sessions have been scheduled for IETF 103 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 18:56:47 -0000 Dear Christopher Wood, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. tls Session 1 (2:00 requested) Monday, 5 November 2018, Afternoon Session I 1350-1550 Room Name: Chitlada 2 size: 250 --------------------------------------------- tls Session 2 (1:00 requested) Wednesday, 7 November 2018, Morning Session II 1120-1220 Room Name: Chitlada 1 size: 300 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/103/sessions/tls.ics Request Information: --------------------------------------------------------- Working Group Name: Transport Layer Security Area Name: Security Area Session Requester: Christopher Wood Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 120 Conflicts to Avoid: First Priority: acme cfrg curdle dispatch httpbis mls perc quic rtcweb stir saag secdispatch suit teep tokbind uta Second Priority: dprive ace Third Priority: tcpinc lamps sidrops People who must be present: Eric Rescorla Rich Salz Sean Turner Joseph A. Salowey Hannes Tschofenig Yoav Nir Martin Thomson Daniel Kahn Gillmor Benjamin Kaduk Christopher A. Wood Nick Sullivan Subodh Iyengar David Benjamin Kyle Nekritz Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Oct 22 10:20:05 2018 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1EE130EBC; Mon, 22 Oct 2018 10:19:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <154022879439.6878.6442051759363048123@ietfa.amsl.com> Date: Mon, 22 Oct 2018 10:19:54 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-esni-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 17:20:03 -0000 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 : Encrypted Server Name Indication for TLS 1.3 Authors : Eric Rescorla Kazuho Oku Nick Sullivan Christopher A. Wood Filename : draft-ietf-tls-esni-02.txt Pages : 21 Date : 2018-10-22 Abstract: This document defines a simple mechanism for encrypting the Server Name Indication for TLS 1.3. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-esni-02 https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-esni-02 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/ From nobody Mon Oct 22 13:47:28 2018 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C7227130EBD; Mon, 22 Oct 2018 13:47:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <154024123876.14115.3623570745276095932@ietfa.amsl.com> Date: Mon, 22 Oct 2018 13:47:18 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-dtls-connection-id-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 20:47:26 -0000 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 : Connection Identifiers for DTLS 1.2 Authors : Eric Rescorla Hannes Tschofenig Thomas Fossati Tobias Gondrom Filename : draft-ietf-tls-dtls-connection-id-02.txt Pages : 11 Date : 2018-10-22 Abstract: This document specifies the Connection ID construct for the Datagram Transport Layer Security (DTLS) protocol version 1.2. A Connection ID is an identifier carried in the record layer header that gives the recipient additional information for selecting the appropriate security association. In "classical" DTLS, selecting a security association of an incoming DTLS record is accomplished with the help of the 5-tuple. If the source IP address and/or source port changes during the lifetime of an ongoing DTLS session then the receiver will be unable to locate the correct security context. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-dtls-connection-id-02 https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls-connection-id-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls-connection-id-02 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/ From nobody Tue Oct 23 10:18:21 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF229124C04 for ; Tue, 23 Oct 2018 10:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhjm25oIz3rN for ; Tue, 23 Oct 2018 10:18:16 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0113.outbound.protection.outlook.com [104.47.38.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BF27130E59 for ; Tue, 23 Oct 2018 10:18:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EYXgQTcpQeAnYNo8yZYPV80gS5hp7UdiL+aJ7q7n1SQ=; b=Q5t1YO/7PcwsjMJs8IcneQYKUAFuzNjG3Fqf9xjGi/1PQ2QTnHl2esT7/8GQSNuVQVvd7l7XS77RhPSfHYpe1EyJt807Yo09+uzE6wsac8PvgrWlYELDCdWnKy4vmyP08X9adyj5JeM8s1PvrFY9EqoiSjegvh7nW2rnYn8Lg6A= Received: from MWHPR22MB0991.namprd22.prod.outlook.com (10.171.145.21) by MWHPR22MB0271.namprd22.prod.outlook.com (10.173.53.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1273.18; Tue, 23 Oct 2018 17:18:12 +0000 Received: from MWHPR22MB0991.namprd22.prod.outlook.com ([fe80::85f2:7e94:3804:4c5b]) by MWHPR22MB0991.namprd22.prod.outlook.com ([fe80::85f2:7e94:3804:4c5b%4]) with mapi id 15.20.1250.028; Tue, 23 Oct 2018 17:18:12 +0000 From: Mike Bishop To: "tls@ietf.org" Thread-Topic: Multi-CDN and ESNI Thread-Index: AdRq7wRx4zTllXqmTJ2fKcMd2QPeYw== Date: Tue, 23 Oct 2018 17:18:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [2601:600:8080:701:3d19:2458:2665:680d] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR22MB0271; 6:qcl9bz6F4/mkF+7MN0C3VyrPkbZ0ahVcl7shO9r39csu48Xvwb0i2q/TToHAlWRyTVirV55GhiSoSqAa3xYzCe7JU4G9IDecveUVbUP77cirY2ckeNTC9pXXc6b8KCF33mz0EYUdvxlSh8CAhQaPqES0FkQY1Jrgjo11B0T70SH9Vs/aXPCZWtjZ4Y3xvUn8A2G8fzJRX0jhkFjuzR8PpI/+p7izqUpbuYvWMvyBlQ7YpHnPGtehIJlWBW8IxfI9ERqzfoPmovJsYE7NmtL/ZuRpzyq9uhrBWz0GZlQkVmCTPjcKL0EgsIVSGmE6SnHBzyt3ZxmCxr1zBPr4XGrd4HFW0JEiVs3XHBa/3j9bv/fAFXdLQ6i7EEvar/XCyqGhmRcO8Svctfjfz76CAOvpuwo0IFapQKll+HUHmtdLskvQcJZ/zR8FxpLCuCbzGme1uSReR+IqZ9AdSujA2VGc1g==; 5:l9p/lYyyl17If74MCKmeebWV4ovDbmFOsNag7EfYrjVh5BD0iYE3J/REp6Bw9ZIj0d6OIwW6sThfrXjG3pj+LWb7tMgk4RUcGKAT9Wn3dz7MManHQodbgin2t1LYnZcfAqwI0Y5Y/gTn5d5eJDRdg5K9c3Q01fhVAlWGqPG8lGs=; 7:iqwDGX3F7QqJvaUIbaVISYjCJi4DPJpDzIWpStr8ZVMB0Mq1yYhQivDqC3rrKXkax4DJyO4M8wsRw35zE5eMexNvqbUVj1w+j7oub7myb8l4nKIX71zTeYAFzigJcNXpEgI0UQxhddBBsOlo1mjLNQ== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: c089c226-e368-4f3e-e1bf-08d6390b82e4 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(7021145)(8989299)(5600074)(711020)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(2017052603328)(7153060)(7193020); SRVR:MWHPR22MB0271; x-ms-traffictypediagnostic: MWHPR22MB0271: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(35073007944872)(150554046322364)(269456686620040)(158342451672863)(21748063052155)(28532068793085)(190501279198761)(227612066756510); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231355)(944501410)(4982022)(52105095)(10201501046)(148016)(149066)(150057)(6041310)(20161123564045)(20161123562045)(20161123558120)(2016111802025)(20161123560045)(6043046)(201708071742011)(7699051)(76991095); SRVR:MWHPR22MB0271; BCL:0; PCL:0; RULEID:; SRVR:MWHPR22MB0271; x-forefront-prvs: 0834BAF534 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(136003)(39830400003)(396003)(376002)(189003)(199004)(74482002)(46003)(476003)(5660300001)(5250100002)(486006)(2501003)(256004)(105586002)(106356001)(33656002)(14454004)(316002)(8936002)(68736007)(1730700003)(6916009)(71190400001)(8676002)(71200400001)(81156014)(81166006)(3480700004)(186003)(508600001)(102836004)(86362001)(7696005)(25786009)(74316002)(7736002)(6506007)(9686003)(53936002)(6306002)(54896002)(55016002)(2351001)(2906002)(99286004)(6436002)(790700001)(97736004)(6116002)(2900100001)(5630700001)(5640700003); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR22MB0271; H:MWHPR22MB0991.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: MB/E8pD2x3656J7N6EvVnVk0/Ytd3KuTH5OINZJayNc8tru2NL/AS1BMzMDbW9ahInSqG2KowtZBIHxkZSR0uGXUXIMbjgjPvquyJ0phCyj0v5olJtC145M2szqpRNUMkpYdimlLGPQW04r1Q6fjlo8IeLtuGRhBMDUbChRl/iSeX8utVLpQAryLGy5FBLB1EIDaLS1PyBoEdf/20OxbLz2VbQfoNH6szUiJM66BGqkGjn8uYYIaIWhrYeOGRftwwYifFunDS3OtenP2qVeXIdNkN4XA+GkdnzvGB7wYkf809ZTL2d8sqsPprsDP/ijshPiycLhIc+xCLS6yYosaUEsTBm72uj1fasnBCAumV4I= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR22MB0991CFCBD60ED526859A1265DAF50MWHPR22MB0991namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: c089c226-e368-4f3e-e1bf-08d6390b82e4 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2018 17:18:12.0621 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR22MB0271 Archived-At: Subject: [TLS] Multi-CDN and ESNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 17:18:20 -0000 --_000_MWHPR22MB0991CFCBD60ED526859A1265DAF50MWHPR22MB0991namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As we discussed in Montreal, the ESNI draft doesn't seem to interact well w= ith origins which use multiple unrelated CDNs. While Section 7.2.2 says th= at the scope of key sharing is between all hosts which can respond to a sin= gle IP address, but the DNS lookup method described actually makes it apply= to all hosts responding to any IP address to which the target hostname mig= ht resolve. The conflict between these two generates the issue. It would appear that there are two deployment models which are possible wit= h the current draft: Customers provide the ESNI keys to the CDN This implies that the client will publish the TXT records directly and use = the same keys across all CDNs they use to serve traffic. This seems to be = possible, since the ESNI extension carries the record_digest of the record;= CDNs use the record_digest to look up the key which it should use to decry= pt the extension. However, an attacker can guess-and-check by resolving a particular domain a= nd checking whether the record_digest returned matches that seen on an insp= ected connection. If record_digests are unique per origin (or at least per= customer's set of origins), ESNI protects relatively little. Therefore, I= presume that the desire is for ESNI keys to be the same for all / large po= pulations of a CDN's customers. CDN uses the same ESNI keys for all customers This implies the CDN will be the one generating keys and publishing the ESN= I records; the client domain will use CNAMEs to point to the CDN's ESNI rec= ord. However, a common strategy for load sharing between CDNs is to provid= e different CNAME responses to the desired portion of traffic. If the CNAM= E returned during an A/AAAA query differs from the CNAME returned during a = TXT query, the server receiving the traffic will be unable to decrypt the S= NI. As far as I'm aware, DNS provides no mechanism to guarantee this selec= tion will be atomic. (Incidentally, you say in 6.2 that this will probably result in an invalid = identity which doesn't chain to a public trust root; it might very well be = a trusted certificate, albeit for the wrong name.) Fundamentally, it seems like the choice of CDN and the choice of ESNI param= eters have to be delivered to clients together and with comparable TTLs; th= e TXT record design makes it difficult to do that. Embedding the ESNI info= rmation in Alt-Svc would be an HTTP-specific solution, but might be an alte= rnative we should consider. If there's a more general-purpose way of ensuring the information is delive= red consistently without compromising privacy, I'm happy to see it solved i= n a non-HTTP manner instead / as well. One such option, which I think some= one raised in Montreal, might be to bind the ESNI record to the in-addr.arp= a/ip6.arpa name for the resolved IP address instead of to the hostname. Th= is necessarily serializes the DNS queries, which is sub-optimal for perform= ance. More fatally, server operators in general are less likely to control= this namespace. --_000_MWHPR22MB0991CFCBD60ED526859A1265DAF50MWHPR22MB0991namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As we discussed in Montreal, the ESNI draft doesn= 217;t seem to interact well with origins which use multiple unrelated CDNs.=   While Section 7.2.2 says that the scope of key sharing is between al= l hosts which can respond to a single IP address, but the DNS lookup method described actually makes it apply to all hosts r= esponding to any IP address to which the target hostname might resolve.&nbs= p; The conflict between these two generates the issue.

 

It would appear that there are two deployment models= which are possible with the current draft:

 

Customers provide the ESNI keys to the CDN

 

This implies that the client will publish the TXT re= cords directly and use the same keys across all CDNs they use to serve traf= fic.  This seems to be possible, since the ESNI extension carries the = record_digest of the record; CDNs use the record_digest to look up the key which it should use to decrypt the extens= ion.

 

However, an attacker can guess-and-check by resolvin= g a particular domain and checking whether the record_digest returned match= es that seen on an inspected connection.  If record_digests are unique= per origin (or at least per customer’s set of origins), ESNI protects relatively little.  Therefore, I presu= me that the desire is for ESNI keys to be the same for all / large populati= ons of a CDN’s customers.

 <= /span>

CDN uses the same ESNI keys for all customers

 

This implies the CDN will be the one generating keys= and publishing the ESNI records; the client domain will use CNAMEs to poin= t to the CDN’s ESNI record.  However, a common strategy for load= sharing between CDNs is to provide different CNAME responses to the desired portion of traffic.  If the CNAME retu= rned during an A/AAAA query differs from the CNAME returned during a TXT qu= ery, the server receiving the traffic will be unable to decrypt the SNI.&nb= sp; As far as I’m aware, DNS provides no mechanism to guarantee this selection will be atomic.

 

(Incidentally, you say in 6.2 that this will probabl= y result in an invalid identity which doesn’t chain to a public trust= root; it might very well be a trusted certificate, albeit for the wrong na= me.)

 <= /p>

 

Fundamentally, it seems like the choice of CDN and t= he choice of ESNI parameters have to be delivered to clients together and w= ith comparable TTLs; the TXT record design makes it difficult to do that.&n= bsp; Embedding the ESNI information in Alt-Svc would be an HTTP-specific solution, but might be an alternative we= should consider.

 

If there’s a more general-purpose way of ensur= ing the information is delivered consistently without compromising privacy,= I’m happy to see it solved in a non-HTTP manner instead / as well.&n= bsp; One such option, which I think someone raised in Montreal, might be to bind the ESNI record to the in-addr.arpa/ip6.arpa= name for the resolved IP address instead of to the hostname.  This ne= cessarily serializes the DNS queries, which is sub-optimal for performance.=   More fatally, server operators in general are less likely to control this namespace.

--_000_MWHPR22MB0991CFCBD60ED526859A1265DAF50MWHPR22MB0991namp_-- From nobody Tue Oct 23 10:58:52 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 118FC130E50 for ; Tue, 23 Oct 2018 10:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.171 X-Spam-Level: X-Spam-Status: No, score=-1.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXAxNMTs3EgW for ; Tue, 23 Oct 2018 10:58:49 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5833F130E1D for ; Tue, 23 Oct 2018 10:58:49 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.23/8.16.0.23) with SMTP id w9NHv69p005955; Tue, 23 Oct 2018 18:58:46 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=Mk7vhlU8VyuleKKRFOD/lP6OFr0GfLlP+ydEJHzdy8M=; b=RBBxDaagxUvkNMHpVBlaZvu77bAfjDvZ48qyOhhgZLcPSKvvzBZy4Dj4JbgCaqNlfyeo 1MOobRrCBj9XcVew0OAUSqlYHfrKNQZNEgEZOvYoWw3rVYg9x8RcIdoygSja7YGV3lvC 1eYjocP1TepgjBT7EoZSz48v6Urfz/Wjn0lB2eUQCijhFKl/JAiqskrfJrWR7eOq+mIS kszef6uP2Jubz/6VXvG/qy3Iqn0waPdGR3xoDmNwPL7zf98ilMt5wwEQle4ET5f7RJWE 9YdjWuQPlWfyNuHI/TimJOEv2lbbMqEwmzVZoULD1NCQVLni/nXCFljknhqXxpWuQFr4 gg== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050102.ppops.net-00190b01. with ESMTP id 2na00jt16q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Oct 2018 18:58:45 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w9NHni3d008738; Tue, 23 Oct 2018 13:58:45 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2n7ypvduw4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 23 Oct 2018 13:58:44 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 23 Oct 2018 13:58:43 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1365.000; Tue, 23 Oct 2018 13:58:42 -0400 From: "Salz, Rich" To: Mike Bishop , "tls@ietf.org" Thread-Topic: [TLS] Multi-CDN and ESNI Thread-Index: AQHUavoI2p9P3cl/z0GLHKPS/8dcYw== Date: Tue, 23 Oct 2018 17:58:42 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.12.0.181014 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.57] Content-Type: multipart/alternative; boundary="_000_DDE6F8E966354D69802883D49E9D7437akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-23_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=841 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810230144 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-23_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=841 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810230145 Archived-At: Subject: Re: [TLS] Multi-CDN and ESNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 17:58:51 -0000 --_000_DDE6F8E966354D69802883D49E9D7437akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayBwZXJoYXBzIHdlIG5lZWQgdG8gdGFrZSBhIHN0ZXAgYmFjayBhbmQgZXhwbGFpbiBz b21ldGhpbmcgdGhhdCBtaWdodCBub3QgYmUgd2VsbC1rbm93biBvdXRzaWRlIHRoZSBjb21tdW5p dHkgb2YgQ0RO4oCZcyBhbmQgdGhlaXIgY3VzdG9tZXJzLiAgSXQgaXMgbm90IHVuY29tbW9uIGZv ciAoYWRtaXR0ZWRseSBsYXJnZXIpIG9yaWdpbnMgdG8gdXNlIG11bHRpcGxlIENETuKAmXMsIGFu ZCB0byBzd2l0Y2ggYW1vbmcgdGhlbS4gVGhpcyBjYW4gYmUgZG9uZSBvbiBhIHBlci1yZXF1ZXN0 IGJhc2lzLCBiZWNhdXNlIG9mIHRoaW5ncyBsaWtlIGNvbnRyYWN0dWFsIGFycmFuZ2VtZW50cyB0 aGF0IG1ha2Ugb25lIHByZWZlcmFibGUsIG9yIGl0IGNhbiBiZSBkb25lIGdsb2JhbGx5IGJ1dCBz d2l0Y2hlZCBpbiBhIG1hdHRlciBvZiBzZWNvbmRzIGJlY2F1c2Ugb2YgYSBzaG9ydCBUVEwgb24g dGhlIHd3dy5leGFtcGxlLmNvbTxodHRwOi8vd3d3LmV4YW1wbGUuY29tPiBlbnRyeS4NCg0KVGhl IGlzc3VlcyB0aGF0IE1pa2UgZGlzY3Vzc2VzIGltcGFjdCBvbiB0aGlzLCBzb21ld2hhdCBuZWdh dGl2ZWx5Lg0KDQpBIHF1aWNrIGhhY2sgdGhvdWdodCBpcyB0byBhbGxvdyBtdWx0aXBsZSBlbnRy aWVzIGluIHRoZSBUWFQgcmVjb3JkLCBmb3JjaW5nIGEgd2VlIGJpdCBtb3JlIHdvcmsgb24gdGhl IENETi4NCg0K --_000_DDE6F8E966354D69802883D49E9D7437akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <017269B63C5BE14CBC41249A05A4E359@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdy YXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4t cmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNv bm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWls U3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHBl cmhhcHMgd2UgbmVlZCB0byB0YWtlIGEgc3RlcCBiYWNrIGFuZCBleHBsYWluIHNvbWV0aGluZyB0 aGF0IG1pZ2h0IG5vdCBiZSB3ZWxsLWtub3duIG91dHNpZGUgdGhlIGNvbW11bml0eSBvZiBDRE7i gJlzIGFuZCB0aGVpciBjdXN0b21lcnMuJm5ic3A7IEl0IGlzIG5vdCB1bmNvbW1vbiBmb3IgKGFk bWl0dGVkbHkgbGFyZ2VyKSBvcmlnaW5zIHRvIHVzZSBtdWx0aXBsZSBDRE7igJlzLCBhbmQgdG8g c3dpdGNoDQogYW1vbmcgdGhlbS4gVGhpcyBjYW4gYmUgZG9uZSBvbiBhIHBlci1yZXF1ZXN0IGJh c2lzLCBiZWNhdXNlIG9mIHRoaW5ncyBsaWtlIGNvbnRyYWN0dWFsIGFycmFuZ2VtZW50cyB0aGF0 IG1ha2Ugb25lIHByZWZlcmFibGUsIG9yIGl0IGNhbiBiZSBkb25lIGdsb2JhbGx5IGJ1dCBzd2l0 Y2hlZCBpbiBhIG1hdHRlciBvZiBzZWNvbmRzIGJlY2F1c2Ugb2YgYSBzaG9ydCBUVEwgb24gdGhl DQo8YSBocmVmPSJodHRwOi8vd3d3LmV4YW1wbGUuY29tIj53d3cuZXhhbXBsZS5jb208L2E+IGVu dHJ5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgaXNzdWVzIHRoYXQgTWlrZSBkaXNjdXNz ZXMgaW1wYWN0IG9uIHRoaXMsIHNvbWV3aGF0IG5lZ2F0aXZlbHkuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkEgcXVpY2sgaGFjayB0aG91Z2h0IGlzIHRvIGFsbG93IG11bHRpcGxlIGVudHJpZXMg aW4gdGhlIFRYVCByZWNvcmQsIGZvcmNpbmcgYSB3ZWUgYml0IG1vcmUgd29yayBvbiB0aGUgQ0RO LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DDE6F8E966354D69802883D49E9D7437akamaicom_-- From nobody Tue Oct 23 13:45:26 2018 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 43EAE12426A; Tue, 23 Oct 2018 13:45:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <154032752420.31401.13837231745826906444@ietfa.amsl.com> Date: Tue, 23 Oct 2018 13:45:24 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-dtls13-29.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 20:45:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 Authors : Eric Rescorla Hannes Tschofenig Nagendra Modadugu Filename : draft-ietf-tls-dtls13-29.txt Pages : 47 Date : 2018-10-23 Abstract: This document specifies Version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is intentionally based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-dtls13-29 https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-29 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls13-29 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/ From nobody Tue Oct 23 14:28:13 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B2A130DC7 for ; Tue, 23 Oct 2018 14:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ducksong.com header.b=LRBAEhY1; dkim=pass (2048-bit key) header.d=outbound.mailhop.org header.b=bOCVcfJZ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-B2UPiujtsX for ; Tue, 23 Oct 2018 14:28:09 -0700 (PDT) Received: from outbound1.eu.mailhop.org (outbound1.eu.mailhop.org [52.28.251.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 789F5130D7A for ; Tue, 23 Oct 2018 14:28:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540330087; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=qQXAJs49JA4pXQ4vR59cm6ZQygnG1JAbXwCJmXMTgRDEIv4UrTVKKeOyz4kFQlRZBtl8uCpmJFU9S UAjTVl3xVtoY73BLOiXag9lEaiptEHWMPZZFp22H2+jDwrqpfZ7utPaQJ0HuS4mDoxG19/9mC0bZ12 PZEVCoXqk9H2lm0dF07SFInfoRIW7IOiao5jcIenNyeS6gZFJ104tcNd4gmPOpEf4qhC94TJA3xNQx 629LZMYB7DFjBhTqDgfTKSahU9k0TtK+kO+jOgz6GGYt/Y4dMO0/ZPyeEq67PRKtGUw7Ua9ipXSleX H/g7VPKNODMINC5gtJjgS10vHyfvezA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:dkim-signature:dkim-signature:from; bh=uFv/2v2V+ZWUpCRa19wTVyT+aSnzQVfZbd66CD7NhzA=; b=Jqf32F3flC0hrctQmQF33z7AtU9G6rmiCPfRcPUEj6MHpvYEAXA1aVUKHUSAry6SqeGijJUgcwE7a TwYRdjhUxMkzq2Q6cmud4EJ209czT0ziAOsJteRncpuLHuiVJqQ5bLeyMM7dRWtnwO7nl+ZmRVtciR Mhd+D60NC785BQqdnKHHbxh+yU9KXVSb6qSXNm/awwyZ8fvDd6zHEEUGtVV2BPtbozqZRXJMrcW8UE FimlDIszH5QvElGVAx40f8nSAxr3+vklkaIor3r2JnZy31Ny5yqQUP25UFVXdkuXi8RXBwBCA9s50+ zR7UkTvdJcgiSmye5TGsuR7fCMwXkNA== ARC-Authentication-Results: i=1; outbound1.eu.mailhop.org; spf=pass smtp.mailfrom=ducksong.com smtp.remote-ip=209.85.210.44; dmarc=none header.from=ducksong.com; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ducksong.com; s=duo-1537391512170-ea99bbb3; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=uFv/2v2V+ZWUpCRa19wTVyT+aSnzQVfZbd66CD7NhzA=; b=LRBAEhY1X+fQ5qIEH1iwM3hyq0NpwJZaM7FrqU42h2i9Ik5lhx2TCmCMNy1npulrIW/iy3oYLJpsz cbL3UBdPm532MAEGslDjYSt/TAA9DD1i9XO4VE8LzidT24hx9o8g/REFRhkgk2nvatXxKHisWBjjBP qlDGCFc2nJ/ROiAw= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=uFv/2v2V+ZWUpCRa19wTVyT+aSnzQVfZbd66CD7NhzA=; b=bOCVcfJZlMzZ9KNG4h/TAVpCDJfwW0eQDAWDvatVfZ+hS8gwdhl3vdY/iSKZb9G5m7IHny01evUZt U1tv+VUo4jPCvE1U6b/vNS3EMnTLPMfSh1fB7uYbqupyzXgSHkY77pkU+uaTu1Bf3gGJKjamRsSJX9 ILFDUnIA/mH/6FzTIcnbysqp6Wh3LNSCiTeL+hwj6/zy/1Fi89E+e31SDMWp7eaIdYwgfKahNAzfOj 2sTypk4QpjQ3o/tJNAEX22DnddaQwzb3DHje0sc1IIYXvBQVDpH+V/zF+uDcYa+uakt2GhWJExC5Cx mxSMUhzyHgetEtGhN1+DiSQCh3fgZiw== X-MHO-RoutePath: bWNtYW51cw== X-MHO-User: 853d2dab-d70a-11e8-9048-075f73944867 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 209.85.210.44 X-Mail-Handler: DuoCircle Outbound SMTP Received: from mail-ot1-f44.google.com (unknown [209.85.210.44]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 853d2dab-d70a-11e8-9048-075f73944867; Tue, 23 Oct 2018 21:28:04 +0000 (UTC) Received: by mail-ot1-f44.google.com with SMTP id x4so2934428otg.3 for ; Tue, 23 Oct 2018 14:28:03 -0700 (PDT) X-Gm-Message-State: ABuFfoirTiI4mB90IfFiLflPWJYESPASBOsiCInRF5/L5MoCqVhtjCaV aqihIG4VSdBvEHFBrYJeTmlvz7PIjgiomDpQom0= X-Google-Smtp-Source: ACcGV63pmgl2cmoh47dzgEcxAGaT5x6aVCpfBatiifeJ3/+p4Hpw/lRIsyjtuB95qNRvMktpOYz9Te5kk06FtN9CqZE= X-Received: by 2002:a9d:7616:: with SMTP id k22mr19095675otl.295.1540330081706; Tue, 23 Oct 2018 14:28:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Patrick McManus Date: Tue, 23 Oct 2018 17:27:50 -0400 X-Gmail-Original-Message-ID: Message-ID: To: "Salz, Rich" Cc: Mike Bishop , "" Content-Type: multipart/alternative; boundary="0000000000005b6c810578ec0b19" Archived-At: Subject: Re: [TLS] Multi-CDN and ESNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 21:28:13 -0000 --0000000000005b6c810578ec0b19 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Definitely agree this is something that needs to be addressed.. As Mike notes, the fundamental issue is that there are 2 pieces of information that are statefully related (the key and address) but obtained statelessly from each other and can therefore come from un-coordinated sources. 2 CDNs are commonly un-coordinated sources.. but I've seen this with other kinds of cloud providers too. All of which should be target audiences of ESNI (because they terminate a variety of hostnames on a smaller number of addresses). fwiw there is a muddled github issue open on this in the old individual-draft repo: https://github.com/ekr/draft-rescorla-tls-esni/issues/35 .. which I'll re-open when the tls-wg repo starts being used for this draft. I see three solution spaces. 1] As Rich suggests, you can coordinate the uncoordinated sources to have one keying record to rule them all. I suspect that's actually not good for anonymity unless it somehow had a normalized global set .. and given the one way nature of a CNAME pointer, I feel like this would be really fragile= . 2] you could scope the keys to only be valid for certain addresses by putting the valid addresses in the key record. This wouldn't help you do ESNI when they didn't match, but at least you could avoid hard failure. (or you could ignore the addressing record but that might be a bridge too far?) 3] My preferred approach, you could scope the keys to the same intermediate name. So if www.example.com -> cname www.cdn-a.com -> ESNI record www.cdn-a.com we could make a rule that the ESNI record would only apply to address records with a final intermediate of www.cdn-a.com. (I'm presuming we'll shift from TXT to ESNI RRTYPE without a prefix, but I don't think it matters for this..).. when there is a mismatch you could use the addressing intermediate as a place to try a new ESNI query from.. That's a perf penalty, but its only paid in the hopefully rare case where these things are unsyncd. #3 is admittedly a bit non traditional, but I spent a bit of time looking at the features of DNS APIs that already have the necessary surface to make a query for a new RRTYPE... and the cname intermediates are indeed generally available.. its true of getdns, res_query, the IOS and MacOS interfaces, DnsQuery* on windows, and of course the custom dns stacks in cronet/android and firefox/doh could do it. I hope to work this into a PR.. my first attempt wasn't very readable, but I'll try again tomorrow. -P On Tue, Oct 23, 2018 at 1:59 PM Salz, Rich wrote: > I think perhaps we need to take a step back and explain something that > might not be well-known outside the community of CDN=E2=80=99s and their > customers. It is not uncommon for (admittedly larger) origins to use > multiple CDN=E2=80=99s, and to switch among them. This can be done on a p= er-request > basis, because of things like contractual arrangements that make one > preferable, or it can be done globally but switched in a matter of second= s > because of a short TTL on the www.example.com entry. > > > > The issues that Mike discusses impact on this, somewhat negatively. > > > > A quick hack thought is to allow multiple entries in the TXT record, > forcing a wee bit more work on the CDN. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000005b6c810578ec0b19 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Definitely agree this is something that needs to be a= ddressed..

As Mike notes, = the fundamental issue is that there are 2 pieces of information that are st= atefully related (the key and address) but obtained statelessly from each o= ther and can therefore come from un-coordinated sources. 2 CDNs are commonl= y un-coordinated sources.. but I've seen this with other kinds of cloud= providers too. All of which should be target audiences of ESNI (because th= ey terminate a variety of hostnames on a smaller number of addresses).
=
fwiw there is a muddled github issue open on this in the old= individual-draft repo:=C2=A0https://github.com/ekr/draft-rescorla-tls-esni/issue= s/35 .. which I'll re-open when the tls-wg repo starts being used f= or this draft.

I see three solution spaces.
<= div>
1] As Rich suggests, you can coordinate the uncoordinate= d sources to have one keying record to rule them all. I suspect that's = actually not good for anonymity unless it somehow had a normalized global s= et .. and given the one way nature of a CNAME pointer, I feel like this wou= ld be really fragile.

2] you could scope the keys = to only be valid for certain addresses by putting the valid addresses in th= e key record. This wouldn't help you do ESNI when they didn't match= , but at least you could avoid hard failure. (or you could ignore the addre= ssing record but that might be a bridge too far?)

= 3] My preferred approach, you could scope the keys to the same intermediate= name. So if www.example.com -> c= name www.cdn-a.com -> ESNI record <= a href=3D"http://www.cdn-a.com">www.cdn-a.com we could make a rule that= the ESNI record would only apply to address records with a final intermedi= ate of www.cdn-a.com. (I'm presumi= ng we'll shift from TXT to ESNI RRTYPE without a prefix, but I don'= t think it matters for this..).. when there is a mismatch you could use the= addressing intermediate as a place to try a new ESNI query from.. That'= ;s a perf penalty, but its only paid in the hopefully rare case where these= things are unsyncd.

#3 is admittedly a bit non tr= aditional, but I spent a bit of time looking at the features of DNS APIs th= at already have the necessary surface to make a query for a new RRTYPE... a= nd the cname intermediates are indeed generally available.. its true of get= dns, res_query, the IOS and MacOS interfaces, DnsQuery* on windows, and of = course the custom dns stacks in cronet/android and firefox/doh could do it.=

I hope to work this into a PR.. my first attempt = wasn't very readable, but I'll try again tomorrow.

-P






On Tue, Oct 23, 2018 at 1:59 PM Salz, Rich <rsalz@akamai.com> wrote:

I think perhaps we need to take a step back and expl= ain something that might not be well-known outside the community of CDN=E2= =80=99s and their customers.=C2=A0 It is not uncommon for (admittedly large= r) origins to use multiple CDN=E2=80=99s, and to switch among them. This can be done on a per-request basis, because of things lik= e contractual arrangements that make one preferable, or it can be done glob= ally but switched in a matter of seconds because of a short TTL on the www.example.com en= try.

=C2=A0

The issues that Mike discusses impact on this, somew= hat negatively.

=C2=A0

A quick hack thought is to allow multiple entries in= the TXT record, forcing a wee bit more work on the CDN.

=C2=A0

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000005b6c810578ec0b19-- From nobody Tue Oct 23 17:45:47 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36239128CB7 for ; Tue, 23 Oct 2018 17:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPvkvXl5AYMa for ; Tue, 23 Oct 2018 17:45:41 -0700 (PDT) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FB93126BED for ; Tue, 23 Oct 2018 17:45:41 -0700 (PDT) Received: by mail-ot1-x330.google.com with SMTP id c32so3311486otb.8 for ; Tue, 23 Oct 2018 17:45:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Lhcdf2iEQ5vrICWBhpbT1vlYArpr471rI5Wc0AzusBw=; b=jWcy1wDZG3LRGCoGkOm4SwCVTkO5R7Xl9WTX2hMaJX1MoQCSu0trmfEo7leGXZVQv8 MWZQiwbxOcklVg9AxGv2GObCaz1fuuP+uVVQe27bEDUQt462rjbghZwcereH85QWmRaY dVRvb5CPVT9APxvWQsjSBC9chnlCwmKHr9Oeg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Lhcdf2iEQ5vrICWBhpbT1vlYArpr471rI5Wc0AzusBw=; b=AQFp2Ri0vE2ksC7Er8z2hZh7v4GHkvww+FRcb6zWbEQc6macdfeBNQUzFKHHhqjy9a AWsax5nKvcbIZlao9MRfmroCqHmJfTadmNq9L8TAaNSR76v+/JxKCkp9ZWbxM+oiMtfA GVp/tIvecU5ke+aHtdTlqc6Jnf4WHrrzd9SOLmcME2Oeni64oCcCYnAfWe1gu3YaCLO+ Hc0vLS1JiEqJhlkTEDGzJToscl+JuhdcY3MKEHLoElMVu3FsbIF8z4AtZyN2cPLBywVz iZmOClTkar6FNzj92++hIwPp7qcl4y+kNx8Cma2GWUZvkIem72lj/ML8BjmLWqkHePqX BT0g== X-Gm-Message-State: AGRZ1gKUoxlFyGFun1PVjAplRMgmLSYbGRpl9JZ7BbLWeBgHA9paZtdO aHQ0sLuTGRN18b8mIaVWP0QUJwx6+eOobGR/OZmPVJKo07Y= X-Google-Smtp-Source: AJdET5em2FAZweSxIqKoTeLsG7chIhQnoRo6FDb2wfIROxtD9z3K7HrgKnADsKH3Br+/rxDylzspC6WIM0pQr1DfM5A= X-Received: by 2002:a9d:59c1:: with SMTP id u1mr325436otg.115.1540341940329; Tue, 23 Oct 2018 17:45:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nick Sullivan Date: Tue, 23 Oct 2018 17:45:28 -0700 Message-ID: To: Patrick McManus Cc: "Salz, Rich" , "" Content-Type: multipart/alternative; boundary="0000000000002fedfd0578eeceec" Archived-At: Subject: Re: [TLS] Multi-CDN and ESNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 00:45:44 -0000 --0000000000002fedfd0578eeceec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This line of commentary describes one instance of a more general situation that is unrelated to the multi-provider case: what happens when you connect to a server that doesn't know the ESNI key you're using? This can even happen on a single provider due to DNS caching issues, for example. The two cases are related and there are two features missing from the current ESNI draft that might be useful to mitigate these scenarios: 1) Allow multiple simultaneous ESNI keys. The DNS provider could present ESNI keys from multiple HTTPS providers (perhaps as different DNS records) and the client could choose to send multiple entries in its ESNI extension, each encrypted to a different key. This would likely solve the multi-CDN scenario at the cost of some clienthello bloat. 2) Allow in-band distribution of ESNI keys if the server does not know the ESNI key sent by the client. The server could prove ownership over a specific long-term "fallback key" advertised in the ESNI record (or maybe a fallback domain) when sent a TLS connection for which no ESNI extensions can be decrypted, then in-band send back a new ESNI public key that the client could use to send the SNI in a follow-up message. It's also possible that handshake encryption alone is enough. This might require some TLS message gymnastics, but doesn't seem impossible. I've heard more well-baked versions of this idea batted around by others. (note that this incurs at least one additional round-trip, but considering that a server not having the active ESNI key should be rare, it is likely ok) To comment specifically on your proposals, Patrick, I don't see #3 as a workable solution since many authoritative DNS providers hide the fact that a CNAME is used when returning A/AAAA records. This obfuscates the indirection that would be necessary to do what you propose, and it does it for a good reason (saving round trips on DNS resolution). Furthermore, intermediate values of CNAME chains seems like a brittle mechanism to rely on for policy enforcement. Nick On Tue, Oct 23, 2018 at 2:28 PM Patrick McManus wrote: > Definitely agree this is something that needs to be addressed.. > > As Mike notes, the fundamental issue is that there are 2 pieces of > information that are statefully related (the key and address) but obtaine= d > statelessly from each other and can therefore come from un-coordinated > sources. 2 CDNs are commonly un-coordinated sources.. but I've seen this > with other kinds of cloud providers too. All of which should be target > audiences of ESNI (because they terminate a variety of hostnames on a > smaller number of addresses). > > fwiw there is a muddled github issue open on this in the old > individual-draft repo: > https://github.com/ekr/draft-rescorla-tls-esni/issues/35 .. which I'll > re-open when the tls-wg repo starts being used for this draft. > > I see three solution spaces. > > 1] As Rich suggests, you can coordinate the uncoordinated sources to have > one keying record to rule them all. I suspect that's actually not good fo= r > anonymity unless it somehow had a normalized global set .. and given the > one way nature of a CNAME pointer, I feel like this would be really fragi= le. > > 2] you could scope the keys to only be valid for certain addresses by > putting the valid addresses in the key record. This wouldn't help you do > ESNI when they didn't match, but at least you could avoid hard failure. (= or > you could ignore the addressing record but that might be a bridge too far= ?) > > 3] My preferred approach, you could scope the keys to the same > intermediate name. So if www.example.com -> cname www.cdn-a.com -> ESNI > record www.cdn-a.com we could make a rule that the ESNI record would only > apply to address records with a final intermediate of www.cdn-a.com. (I'm > presuming we'll shift from TXT to ESNI RRTYPE without a prefix, but I don= 't > think it matters for this..).. when there is a mismatch you could use the > addressing intermediate as a place to try a new ESNI query from.. That's = a > perf penalty, but its only paid in the hopefully rare case where these > things are unsyncd. > > #3 is admittedly a bit non traditional, but I spent a bit of time looking > at the features of DNS APIs that already have the necessary surface to ma= ke > a query for a new RRTYPE... and the cname intermediates are indeed > generally available.. its true of getdns, res_query, the IOS and MacOS > interfaces, DnsQuery* on windows, and of course the custom dns stacks in > cronet/android and firefox/doh could do it. > > I hope to work this into a PR.. my first attempt wasn't very readable, bu= t > I'll try again tomorrow. > > -P > > > > > > > On Tue, Oct 23, 2018 at 1:59 PM Salz, Rich wrote: > >> I think perhaps we need to take a step back and explain something that >> might not be well-known outside the community of CDN=E2=80=99s and their >> customers. It is not uncommon for (admittedly larger) origins to use >> multiple CDN=E2=80=99s, and to switch among them. This can be done on a = per-request >> basis, because of things like contractual arrangements that make one >> preferable, or it can be done globally but switched in a matter of secon= ds >> because of a short TTL on the www.example.com entry. >> >> >> >> The issues that Mike discusses impact on this, somewhat negatively. >> >> >> >> A quick hack thought is to allow multiple entries in the TXT record, >> forcing a wee bit more work on the CDN. >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000002fedfd0578eeceec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This line of commentary describes one instance of a m= ore general situation that is unrelated to the multi-provider case: what ha= ppens when you connect to a server that doesn't know the ESNI key you&#= 39;re using? This can even happen on a single provider due to DNS caching i= ssues, for example.=C2=A0

The two cases are relate= d and there are two features missing from the current ESNI draft that might= be useful to mitigate these scenarios:
1) Allow=C2=A0multiple si= multaneous=C2=A0ESNI keys. The DNS provider could present ESNI keys from mu= ltiple HTTPS providers (perhaps as different DNS records) and the client co= uld choose to send multiple entries in its ESNI extension, each encrypted t= o a different key. This would likely solve the multi-CDN scenario at the co= st of some clienthello bloat.
2) Allow in-band distribution of ES= NI keys if the server does not know the ESNI key sent by the client. The se= rver could prove ownership over a specific long-term "fallback key&quo= t; advertised in the ESNI record (or maybe a fallback domain) when sent a T= LS connection for which no ESNI extensions can be decrypted, then in-band s= end back a new ESNI public key that the client could use to send the SNI in= a follow-up message. It's also possible that handshake encryption alon= e is enough. This might require some TLS message gymnastics, but doesn'= t seem impossible. I've heard more well-baked versions of this idea bat= ted around by others. (note that this incurs at least one additional round-= trip, but considering that a server not having the active ESNI key should b= e rare, it is likely ok)

To comment specifica= lly=C2=A0on your proposals, Patrick, I don't see #3 as a workable solut= ion since many authoritative DNS providers hide the fact that a CNAME is us= ed when returning A/AAAA records. This obfuscates the indirection that woul= d be necessary to do what you propose, and it does it for a good reason (sa= ving round trips on DNS resolution). Furthermore, intermediate values of CN= AME chains seems like a brittle mechanism to rely on for policy enforcement= .

Nick

On Tue, Oct 23, 2018 at 2:28 PM Patrick McManus &= lt;mcmanus@ducksong.com> wro= te:
Definitel= y agree this is something that needs to be addressed..

As Mike notes, the fundamental issue is that t= here are 2 pieces of information that are statefully related (the key and a= ddress) but obtained statelessly from each other and can therefore come fro= m un-coordinated sources. 2 CDNs are commonly un-coordinated sources.. but = I've seen this with other kinds of cloud providers too. All of which sh= ould be target audiences of ESNI (because they terminate a variety of hostn= ames on a smaller number of addresses).

fwiw there is a = muddled github issue open on this in the old individual-draft repo:=C2=A0https://github.com/ekr/draft-rescorla-tls-esni/issues/35 ..= which I'll re-open when the tls-wg repo starts being used for this dra= ft.

I see three solution spaces.

1] As Rich suggests, you can coordinate the uncoordinated sources t= o have one keying record to rule them all. I suspect that's actually no= t good for anonymity unless it somehow had a normalized global set .. and g= iven the one way nature of a CNAME pointer, I feel like this would be reall= y fragile.

2] you could scope the keys to only be = valid for certain addresses by putting the valid addresses in the key recor= d. This wouldn't help you do ESNI when they didn't match, but at le= ast you could avoid hard failure. (or you could ignore the addressing recor= d but that might be a bridge too far?)

3] My prefe= rred approach, you could scope the keys to the same intermediate name. So i= f www.example.com = -> cname www.cdn-a.co= m -> ESNI record = www.cdn-a.com we could make a rule that the ESNI record would only appl= y to address records with a final intermediate of www.cdn-a.com. (I'm presuming we'll s= hift from TXT to ESNI RRTYPE without a prefix, but I don't think it mat= ters for this..).. when there is a mismatch you could use the addressing in= termediate as a place to try a new ESNI query from.. That's a perf pena= lty, but its only paid in the hopefully rare case where these things are un= syncd.

#3 is admittedly a bit non traditional, but= I spent a bit of time looking at the features of DNS APIs that already hav= e the necessary surface to make a query for a new RRTYPE... and the cname i= ntermediates are indeed generally available.. its true of getdns, res_query= , the IOS and MacOS interfaces, DnsQuery* on windows, and of course the cus= tom dns stacks in cronet/android and firefox/doh could do it.
I hope to work this into a PR.. my first attempt wasn't ver= y readable, but I'll try again tomorrow.

-P






On Tue, Oct 23, 2018 at 1:59 PM Salz, Ric= h <rsalz@akamai.co= m> wrote:

I think perhaps we need to take a step back and expl= ain something that might not be well-known outside the community of CDN=E2= =80=99s and their customers.=C2=A0 It is not uncommon for (admittedly large= r) origins to use multiple CDN=E2=80=99s, and to switch among them. This can be done on a per-request basis, because of things lik= e contractual arrangements that make one preferable, or it can be done glob= ally but switched in a matter of seconds because of a short TTL on the www.example.com en= try.

=C2=A0

The issues that Mike discusses impact on this, somew= hat negatively.

=C2=A0

A quick hack thought is to allow multiple entries in= the TXT record, forcing a wee bit more work on the CDN.

=C2=A0

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000002fedfd0578eeceec-- From nobody Tue Oct 23 19:19:08 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42A0130E41 for ; Tue, 23 Oct 2018 19:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhLu6WqtosB8 for ; Tue, 23 Oct 2018 19:19:05 -0700 (PDT) Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72C4C130DD2 for ; Tue, 23 Oct 2018 19:19:05 -0700 (PDT) Received: by mail-vs1-xe35.google.com with SMTP id j20so972465vso.8 for ; Tue, 23 Oct 2018 19:19:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=abpZQqnyx6qPDlj0i5wgB1Yxo1i9WVd4LXSrq1OdDLs=; b=DxZKXaETFJxIrzBQtZFGyQ3JOrGQnRerz8lx7ZVAHUE4CjGD2XtTeWV87moO5qV3iW TecHxtYWoRzLqUR2w3RXzRpTszMBzsKLXS7SsfDr5TsIESWW+njX1N5mrolhP/VkJzzI CzaH2nJm6jdfwg/MuEIt22NNgfhbuvEJ32r39KgekXz/94rqdu8qbtBiSqkD7STBK0KN mhMAdbCJuFZodZpQmQ4WwZjC4NDC0IMAl6AvBn6nKVjw7g25inMkhgLk2MkIZDeTlceA bsYiE8t0gtqFUKGGjIyJ+gSMHLmXU2t9N7z3gBb49xT14KI2eao/a1Oygk2kEfzH6w9v g3cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=abpZQqnyx6qPDlj0i5wgB1Yxo1i9WVd4LXSrq1OdDLs=; b=t3feknubUpuHoO9cJE+/4VT5CS816Mzz5zXX1u+2iMjIprK4HCc4p/IMpnn8LZ26cc WI5krnW0Ge90aExUo15mrCfT4YLRpRkeG2cNfTwxxBG6Mw5oMskm2lcaW4Gua5bQQjeM XR6fmNkTqpRYEwG81C3Gw1YDZtbXog2UZ90RhcItUtFcV+KRxS2BP4Fh2uCP9arQuBS2 sze3lqH0BPAm28kq8EFgclvT+B4gZ3AEHvDrhk88KagRs7P3AKlAE0J0oDMJ7zvyl80h o4d23rx5/4hlswcVkEjuDA74E9knOoJ/0GVy1cBWsQcmHBsqxyQSyp5noAjQRszVpRtD /mCw== X-Gm-Message-State: AGRZ1gKljEsbu88QCZT5w/C1Wfe2Ux9P+xo+DlHuRq/fQbBWExuwy7pj u3m198DydQfVs08SlYSr2hqaY8mG09lS1lg1NFEEePMY X-Google-Smtp-Source: AJdET5eukywoWmXlBN+V4ZRkrEHLS2CPQKwI+UYnIJimpUa8sS9kn5E2IlRoXc+k8Nn8uA+iaLO4u/J027f6f+6TVi8= X-Received: by 2002:a67:f096:: with SMTP id i22mr318800vsl.174.1540347544028; Tue, 23 Oct 2018 19:19:04 -0700 (PDT) MIME-Version: 1.0 From: Christopher Wood Date: Tue, 23 Oct 2018 19:18:47 -0700 Message-ID: To: "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [TLS] dnssec_chain pinning issues and discussion X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 02:19:06 -0000 Thanks to those who contributed to the discussion on this topic over the past two weeks. It led to useful insights and clarity around the problem statement, desired use cases, and current state of this draft. (Specifically, Viktor=E2=80=99s summary of the problem statement in [1] was quite helpful and, absent objections, would probably make a nice PR for which we can gauge consensus.) To summarize some of the long discussions, among the primary use cases raised over the lifetime of this draft, we have the following: - Increase availability of DANE records for clients. - Provide an alternative to WebPKI-based server authentication. - Gain operational experience with DANE on clients and servers. - Increase connectivity to DANE-only clients and servers. (This is not a realistic use case in the immediate future.) These are meant to apply to both greenfield and incremental deployment use cases. If there are others, please share them with the list. If anyone feels as though we should not target the incremental deployment use case and instead focus strictly on greenfield applications, or if the current use cases as written are under specified or unclear, please say so, and say why. Minimally, for broad use cases, it seems necessary to have some way to prevent attackers from stripping the additional protection communicated by this extension from the TLS server to the TLS client. Extension pinning of some type would seem to address this particular issue. The text from Paul and Viktor [2] shared before the interim is one specific proposal for this pinning. In the context of this proposal, the following issues have arisen: 1. Servers may make mistakes which lead to connection issues, i.e., it=E2=80=99s a footgun. (Note: The chance of this happening while the extension is not yet universally supported is low.) 2. Malicious pins can be set by an adversary who can modify the victim's DNSSEC records. This can force the TLS client to use the extension for a long time, even after correcting the DNSSEC compromise. 3. Some sort of in-band (or perhaps out-of-band) alert may be required for pinning to function safely and correctly. 4. Non-universal deployment of the extension within a TLS farm (operator) may make removing the pin difficult since any particular server may not have an implementation of the extension. If you feel any of these are non-issues, please say so, and say why. If you feel any of these issues are incorrect, please say so, and say why. The chairs would like to have all issues with the *current* pinning proposal aired and discussed before Bangkok. That will allow us to asses the proposal and whether or not it satisfies the desired use cases. Note that this list may not be exhaustive. Thus, if there are other omitted issues that have been raised, please share them with the list for discussion. Thanks, Chris, Joe, and Sean [1] https://mailarchive.ietf.org/arch/msg/tls/OWxALokRtxNcaFdPyNiHTOt_wjQ [2] https://github.com/tlswg/dnssec-chain-extension/compare/0664d5a608bc2cd= 82967370160fd4b837dba8fab...vdukhovni:for-interim From nobody Wed Oct 24 08:37:26 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED07612D4E8 for ; Wed, 24 Oct 2018 08:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ducksong.com header.b=R+XrZSav; dkim=pass (2048-bit key) header.d=outbound.mailhop.org header.b=MndS1gMu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6llCYrqmiomE for ; Wed, 24 Oct 2018 08:37:17 -0700 (PDT) Received: from outbound2n.ore.mailhop.org (outbound2n.ore.mailhop.org [54.186.218.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81D8E128BCC for ; Wed, 24 Oct 2018 08:37:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540395437; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=RnuuF8LtOW+eP20WfNz3Hb6oEJu9XQC+kWJ2VHXRyKABK2/ktbHzQwVCGC5Zk8Ic6suR6j9hT7d/D U7MX6m19/u8nFCNycaeVeU/yaXQXuC3MUT9m6nYSLzDM0LwcnBQ8lNAAYbzLgKzUxXwY3PWw4moQbI eE1zPVukm5Gn5djIiMZYa90iDw6exiFUJMIqSHfojnFIcxwT5e7FkWmCOICo0MJxV7hZADiVGXvg2K BOujAuNEhaEou+tLNXpQiqC+xNL62N9Tnq+5A2DQ8AHNFj0x1ES+pH5h/Z3A/OugNroQ6dCKPzVm4K vn88gNmwq6zFxkEvbpoQK5pwVUWpDqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:dkim-signature:dkim-signature:from; bh=ZLtBLo3wZXDEexshGhNfsomb8A/gXIdtGDyF+i87lDU=; b=RPvjqalEO049C2fMkyQBRy6cknz7jM5bv55wMz/l/Fii3MaA9PHbCKAW8prxkdNLh5eS/aQn5EIDg VusWyV9pQmQlB1q0ocuHo55qSTPiPvbkjtUdNKD3rymTeWC4n8dBwOoiFyPzZmqGaamaKj0QPEAUFq MN6ub8nlz8ulwsT3iuqc+p3O8adifho9DnWampgnVYvtA7PfzmI4ti3Z22PV1H1nBaaXEdGkCODHdd PLTrrCZl/07NdXxYtdiC1xI8EHRFs1VvQQlYGKTabVqXkf2hSHZA5afn7ShAWeBF+SNlL7jNYMdbyY v+VvF+oBktUHY8/Astnxqp1au3Q9bzg== ARC-Authentication-Results: i=1; outbound2.ore.mailhop.org; spf=pass smtp.mailfrom=ducksong.com smtp.remote-ip=209.85.210.45; dmarc=none header.from=ducksong.com; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ducksong.com; s=duo-1537391512170-ea99bbb3; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=ZLtBLo3wZXDEexshGhNfsomb8A/gXIdtGDyF+i87lDU=; b=R+XrZSavILGCXGMs1VL8tnmBfj+YL+7yThcaQEP1G0MYCLHes6OgbNYmHlUKgDgoSzP2cSuyFs2BM KznkTxwD+7ftv8fu00IEVhcMMAqo3XbvdNozT45IrGmKV3TAhbPAF225a6WwUMXAwm4VU8x8S+JEzf UbOeQUgSh0i4qE/Q= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=ZLtBLo3wZXDEexshGhNfsomb8A/gXIdtGDyF+i87lDU=; b=MndS1gMudtwL3otwGDJA/Md7fdOoS0TDGwn+iDieT7nyFTon0WLRzI2xnz1qaOJ0HQzj9H+bSmUz4 BVvO99aNpTyE5ocJhVdypb6HQoexz17zBO6R8WjA+ga0oNIZuy8tvFdxVb42+Ce216o+jFSven4hii 4xiful9XzJ89XBQHJqX+E+aYFbIUMYpl1cZksDR9SXIYhnXXN0Yv+XGEFiQoYjo5XPgfIbMXdyZXGn ZzdGlIoJhk0biH3RgnR3Sssq0VELQ+gqv8k70wpucpzcRIoXbNKqq590/m2GvOQeeljWJCFmRGuggd IJeQAXLDcf55yU40TLIEcMpPkRvVi4w== X-MHO-RoutePath: bWNtYW51cw== X-MHO-User: ae8d2b89-d7a2-11e8-a630-335f030b21f2 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 209.85.210.45 X-Mail-Handler: DuoCircle Outbound SMTP Received: from mail-ot1-f45.google.com (unknown [209.85.210.45]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id ae8d2b89-d7a2-11e8-a630-335f030b21f2; Wed, 24 Oct 2018 15:37:15 +0000 (UTC) Received: by mail-ot1-f45.google.com with SMTP id w18so2526217otk.0 for ; Wed, 24 Oct 2018 08:37:15 -0700 (PDT) X-Gm-Message-State: AGRZ1gLOp07PD5w0GJCkE9E4JLEPVJcBKU+sJzqqVbgi19+Na9WvUqNi BD8e7tbMIhVr+UbgBhHND8LEA6SXGICXvJwFsek= X-Google-Smtp-Source: AJdET5d9gIwvEj4OwDsT7QZ0o5r/UO9YgvbrFGqDb39bznL2tLF4fBzPvGzj8kboBVz25YNfbzvFa5+qK3SxyIbf1F8= X-Received: by 2002:a9d:4a09:: with SMTP id h9mr1928953otf.254.1540395434571; Wed, 24 Oct 2018 08:37:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Patrick McManus Date: Wed, 24 Oct 2018 11:37:03 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Nick Sullivan Cc: "Patrick R. McManus" , "Salz, Rich" , "" Content-Type: multipart/alternative; boundary="000000000000b0ffb50578fb42a9" Archived-At: Subject: Re: [TLS] Multi-CDN and ESNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 15:37:22 -0000 --000000000000b0ffb50578fb42a9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Nick, On Tue, Oct 23, 2018 at 8:45 PM Nick Sullivan wrote: > This line of commentary describes one instance of a more general situatio= n > that is unrelated to the multi-provider case: what happens when you conne= ct > to a server that doesn't know the ESNI key you're using? This can even > happen on a single provider due to DNS caching issues, for example. > > The two cases are related and there are two features missing from the > current ESNI draft that might be useful to mitigate these scenarios: > 1) Allow multiple simultaneous ESNI keys. The DNS provider could present > ESNI keys from multiple HTTPS providers (perhaps as different DNS records= ) > and the client could choose to send multiple entries in its ESNI extensio= n, > each encrypted to a different key. This would likely solve the multi-CDN > scenario at the cost of some clienthello bloat. > I would like to see this feature, but I don't think it addresses this problem.. consider load balancer L, CDN A and CDN B. In a world in which L is aware of A and B (duh) but not ESNI, and A wants to deploy ESNI but B has not yet done so. You have the likely situation where at some point you've got an address record for B but a key for only A and you run into hard failure. even if A and B both want to do ESNI they need to be aware of each other and coordinate key rotations somehow to synthesize records - or else you end up spf like includes (please no). Requiring cross provider coordination seems like assuming knowledge the providers don't reliably have and probably could't reliably maintain. You could boot the problem to cusomter configuration but.. 1] esni is so much better as automatic infrastructure so CDNs can just turn it on and 2] origin names may not wish to disclose all of their providers to each other. > 2) Allow in-band distribution of ESNI keys if the server does not know th= e > ESNI key sent by the client. The server could prove ownership over a > specific long-term "fallback key" advertised in the ESNI record (or maybe= a > fallback domain) when sent a TLS connection for which no ESNI extensions > can be decrypted, then in-band send back a new ESNI public key that the > client could use to send the SNI in a follow-up message. It's also possib= le > that handshake encryption alone is enough. This might require some TLS > message gymnastics, but doesn't seem impossible. I've heard more well-bak= ed > versions of this idea batted around by others. (note that this incurs at > least one additional round-trip, but considering that a server not having > the active ESNI key should be rare, it is likely ok) > > My concern would be a legacy TLS stack. The problematic case is when the lookup for ESNI yields a key, but the host at the end of the A record has never heard of it (or perhaps even heard of TLS 1.3). These are different orgs, so its totally possible and inevitable in the sense that there are no flag days. How does that work with this scheme? This is tricky because the failure mode is so painful. provider A can essentially break provider B by deploying ESNI - externalizing some of its own risk. A and B don't have a super reliable way of knowing about each other to even make sane risk judgments. > To comment specifically on your proposals, Patrick, I don't see #3 as a > workable solution since many authoritative DNS providers hide the fact th= at > a CNAME is used when returning A/AAAA records. This obfuscates the > indirection that would be necessary to do what you propose, and it does i= t > for a good reason (saving round trips on DNS resolution). Furthermore, > intermediate values of CNAME chains seems like a brittle mechanism to rel= y > on for policy enforcement. > > Roughly, this is inspired by what krb does with canonical names in practice. And it makes logical sense - the key applies to the canonical name, not the alias. That said - this is a pain point I agree. I'm glad you brought up flattening - I know of a handful of orgs that do that. But do any of them do it across administrative domains or just as optimizations to their own 'zone files'? I understood it to be the latter, and I don't think that would really be a problem here as long as it was consistent across rrtypes. another thought, Kazuho had mentioned reverse lookups at some point. Definitely too painful for the normal case, but perhaps plausible as a fallback? Doing a reverse lookup of the address record to obtain the canonical key for the address (and absence of a reverse-lookup key means that host doesn't really do ESNI so proceed the old way). it would be backwards compatible but I worry both that its too fragile itself (IP addressing can be pretty disjoint from http operations) and perhaps too much of a time penalty to bear given the 'externalization' problem. But let's throw it out there. > Nick > > On Tue, Oct 23, 2018 at 2:28 PM Patrick McManus > wrote: > >> Definitely agree this is something that needs to be addressed.. >> >> As Mike notes, the fundamental issue is that there are 2 pieces of >> information that are statefully related (the key and address) but obtain= ed >> statelessly from each other and can therefore come from un-coordinated >> sources. 2 CDNs are commonly un-coordinated sources.. but I've seen this >> with other kinds of cloud providers too. All of which should be target >> audiences of ESNI (because they terminate a variety of hostnames on a >> smaller number of addresses). >> >> fwiw there is a muddled github issue open on this in the old >> individual-draft repo: >> https://github.com/ekr/draft-rescorla-tls-esni/issues/35 .. which I'll >> re-open when the tls-wg repo starts being used for this draft. >> >> I see three solution spaces. >> >> 1] As Rich suggests, you can coordinate the uncoordinated sources to hav= e >> one keying record to rule them all. I suspect that's actually not good f= or >> anonymity unless it somehow had a normalized global set .. and given the >> one way nature of a CNAME pointer, I feel like this would be really frag= ile. >> >> 2] you could scope the keys to only be valid for certain addresses by >> putting the valid addresses in the key record. This wouldn't help you do >> ESNI when they didn't match, but at least you could avoid hard failure. = (or >> you could ignore the addressing record but that might be a bridge too fa= r?) >> >> 3] My preferred approach, you could scope the keys to the same >> intermediate name. So if www.example.com -> cname www.cdn-a.com -> ESNI >> record www.cdn-a.com we could make a rule that the ESNI record would >> only apply to address records with a final intermediate of www.cdn-a.com= . >> (I'm presuming we'll shift from TXT to ESNI RRTYPE without a prefix, but= I >> don't think it matters for this..).. when there is a mismatch you could = use >> the addressing intermediate as a place to try a new ESNI query from.. >> That's a perf penalty, but its only paid in the hopefully rare case wher= e >> these things are unsyncd. >> >> #3 is admittedly a bit non traditional, but I spent a bit of time lookin= g >> at the features of DNS APIs that already have the necessary surface to m= ake >> a query for a new RRTYPE... and the cname intermediates are indeed >> generally available.. its true of getdns, res_query, the IOS and MacOS >> interfaces, DnsQuery* on windows, and of course the custom dns stacks in >> cronet/android and firefox/doh could do it. >> >> I hope to work this into a PR.. my first attempt wasn't very readable, >> but I'll try again tomorrow. >> >> -P >> >> >> >> >> >> >> On Tue, Oct 23, 2018 at 1:59 PM Salz, Rich wrote: >> >>> I think perhaps we need to take a step back and explain something that >>> might not be well-known outside the community of CDN=E2=80=99s and thei= r >>> customers. It is not uncommon for (admittedly larger) origins to use >>> multiple CDN=E2=80=99s, and to switch among them. This can be done on a= per-request >>> basis, because of things like contractual arrangements that make one >>> preferable, or it can be done globally but switched in a matter of seco= nds >>> because of a short TTL on the www.example.com entry. >>> >>> >>> >>> The issues that Mike discusses impact on this, somewhat negatively. >>> >>> >>> >>> A quick hack thought is to allow multiple entries in the TXT record, >>> forcing a wee bit more work on the CDN. >>> >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > --000000000000b0ffb50578fb42a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hey Nick,

On Tue, Oct 23, 2018 at 8:45 PM Nick Sullivan <nick@cloudflare.com> wrote:
This line of commentary descri= bes one instance of a more general situation that is unrelated to the multi= -provider case: what happens when you connect to a server that doesn't = know the ESNI key you're using? This can even happen on a single provid= er due to DNS caching issues, for example.=C2=A0

T= he two cases are related and there are two features missing from the curren= t ESNI draft that might be useful to mitigate these scenarios:
1)= Allow=C2=A0multiple simultaneous=C2=A0ESNI keys. The DNS provider could pr= esent ESNI keys from multiple HTTPS providers (perhaps as different DNS rec= ords) and the client could choose to send multiple entries in its ESNI exte= nsion, each encrypted to a different key. This would likely solve the multi= -CDN scenario at the cost of some clienthello bloat.

I would like to see this feature, but I don't thi= nk it addresses this problem..=C2=A0

consider load= balancer L, CDN A and CDN B. In a world in which L is aware of A and B (du= h) but not ESNI, and A wants to deploy ESNI but B has not yet done so. You = have the likely situation where at some point you've got an address rec= ord for B but a key for only A and you run into hard failure.
even if A and B both want to do ESNI they need to be aware of e= ach other and coordinate key rotations somehow to synthesize records - or e= lse you end up spf like includes (please no). Requiring cross provider coor= dination seems like assuming knowledge the providers don't reliably hav= e and probably could't reliably maintain. You could boot the problem to= cusomter configuration but.. 1] esni is so much better as automatic infras= tructure so CDNs can just turn it on and 2] origin names may not wish to di= sclose all of their providers to each other.
=C2=A0
2) Allow in-band distribution = of ESNI keys if the server does not know the ESNI key sent by the client. T= he server could prove ownership over a specific long-term "fallback ke= y" advertised in the ESNI record (or maybe a fallback domain) when sen= t a TLS connection for which no ESNI extensions can be decrypted, then in-b= and send back a new ESNI public key that the client could use to send the S= NI in a follow-up message. It's also possible that handshake encryption= alone is enough. This might require some TLS message gymnastics, but doesn= 't seem impossible. I've heard more well-baked versions of this ide= a batted around by others. (note that this incurs at least one additional r= ound-trip, but considering that a server not having the active ESNI key sho= uld be rare, it is likely ok)

<= br>
My concern would be a legacy TLS stack. The problematic case = is when the lookup for ESNI yields a key, but the host at the end of the A = record has never heard of it (or perhaps even heard of TLS 1.3). These are = different orgs, so its totally possible and inevitable in the sense that th= ere are no flag days. How does that work with this scheme?=C2=A0
=
This is tricky because the failure mode is so painful. provi= der A can essentially break provider B by deploying ESNI - externalizing so= me of its own risk. A and B don't have a super reliable way of knowing = about each other to even make sane risk judgments.
=C2=A0
To c= omment specifically=C2=A0on your proposals, Patrick, I don't see #3 as = a workable solution since many authoritative DNS providers hide the fact th= at a CNAME is used when returning A/AAAA records. This obfuscates the indir= ection that would be necessary to do what you propose, and it does it for a= good reason (saving round trips on DNS resolution). Furthermore, intermedi= ate values of CNAME chains seems like a brittle mechanism to rely on for po= licy enforcement.


Roughly, this is inspired by what krb does with canonical names in = practice. And it makes logical sense - the key applies to the canonical nam= e, not the alias. That said - this is a pain point I agree.

<= /div>
I'm glad you brought up flattening - I know of a handful of o= rgs that do that. But do any of them do it across administrative domains or= just as optimizations to their own 'zone files'?=C2=A0 I understoo= d it to be the latter, and I don't think that would really be a problem= here as long as it was consistent across rrtypes.

another thought, Kazuho had mentioned reverse lookups at some point. Defin= itely too painful for the normal case, but perhaps plausible as a fallback?= Doing a reverse lookup of the address record to obtain the canonical key f= or the address (and absence of a reverse-lookup key means that host doesn&#= 39;t really do ESNI so proceed the old way). it would be backwards compatib= le but I worry both that its too fragile itself (IP addressing can be prett= y disjoint from http operations) and perhaps too much of a time penalty to = bear given the 'externalization' problem. But let's throw it ou= t there.


=C2=A0
Nick
<= br>
On Tue, Oct 23, 2018 at 2:28= PM Patrick McManus <mcmanus@ducksong.com> wrote:
Definitely agree this is something that needs= to be addressed..

As Mike= notes, the fundamental issue is that there are 2 pieces of information tha= t are statefully related (the key and address) but obtained statelessly fro= m each other and can therefore come from un-coordinated sources. 2 CDNs are= commonly un-coordinated sources.. but I've seen this with other kinds = of cloud providers too. All of which should be target audiences of ESNI (be= cause they terminate a variety of hostnames on a smaller number of addresse= s).

fwiw there is a muddled github issue open on this in= the old individual-draft repo:=C2=A0https://github.com/ekr/dra= ft-rescorla-tls-esni/issues/35 .. which I'll re-open when the tls-w= g repo starts being used for this draft.

I see thr= ee solution spaces.

1] As Rich suggests, you can c= oordinate the uncoordinated sources to have one keying record to rule them = all. I suspect that's actually not good for anonymity unless it somehow= had a normalized global set .. and given the one way nature of a CNAME poi= nter, I feel like this would be really fragile.

2]= you could scope the keys to only be valid for certain addresses by putting= the valid addresses in the key record. This wouldn't help you do ESNI = when they didn't match, but at least you could avoid hard failure. (or = you could ignore the addressing record but that might be a bridge too far?)=

3] My preferred approach, you could scope the key= s to the same intermediate name. So if www.example.com -> cname www.cdn-a.com -> ESNI record www.cdn-a.com we could make a rule= that the ESNI record would only apply to address records with a final inte= rmediate of www.cdn-a.co= m. (I'm presuming we'll shift from TXT to ESNI RRTYPE without a= prefix, but I don't think it matters for this..).. when there is a mis= match you could use the addressing intermediate as a place to try a new ESN= I query from.. That's a perf penalty, but its only paid in the hopefull= y rare case where these things are unsyncd.

#3 is = admittedly a bit non traditional, but I spent a bit of time looking at the = features of DNS APIs that already have the necessary surface to make a quer= y for a new RRTYPE... and the cname intermediates are indeed generally avai= lable.. its true of getdns, res_query, the IOS and MacOS interfaces, DnsQue= ry* on windows, and of course the custom dns stacks in cronet/android and f= irefox/doh could do it.

I hope to work this into a= PR.. my first attempt wasn't very readable, but I'll try again tom= orrow.

-P






On T= ue, Oct 23, 2018 at 1:59 PM Salz, Rich <rsalz@akamai.com> wrote:

I think perhaps we need to take a step back and expl= ain something that might not be well-known outside the community of CDN=E2= =80=99s and their customers.=C2=A0 It is not uncommon for (admittedly large= r) origins to use multiple CDN=E2=80=99s, and to switch among them. This can be done on a per-request basis, because of things lik= e contractual arrangements that make one preferable, or it can be done glob= ally but switched in a matter of seconds because of a short TTL on the www.example.com en= try.

=C2=A0

The issues that Mike discusses impact on this, somew= hat negatively.

=C2=A0

A quick hack thought is to allow multiple entries in= the TXT record, forcing a wee bit more work on the CDN.

=C2=A0

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000b0ffb50578fb42a9-- From nobody Wed Oct 24 10:05:34 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCCF6130E39 for ; Wed, 24 Oct 2018 10:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.171 X-Spam-Level: X-Spam-Status: No, score=-1.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzo3p_A_EJcL for ; Wed, 24 Oct 2018 10:05:30 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B535E130E9B for ; Wed, 24 Oct 2018 10:05:30 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.23/8.16.0.23) with SMTP id w9OH1s80003074; Wed, 24 Oct 2018 18:05:27 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=Db8/kYdrQTciURiKGm8f6sPEguzRDQ24dR0WIExFHws=; b=UpxFh25NTk0JqVCjtWlWENu6aFFI6i/5fdtwjg5Tfs9uqTC8e1O481Om1FwjpL7hhYf6 XLQU1mhaf6wTqBO39EWLn6x4AlfaKc8Kq4+6vzXShE6TC61erXuLyxaeG7s5ZZK5nzEA G4vNjhWp2py7jIBWPHqZ6OPjxPlpQ5xabocKx0Km5woNFNlHX4IXywvv2sAcSb4PaXAK FumCLShVRj2iyGjEN4Cf9ojIljnGOnWR1Lu5ad/DLOfq8QTlV3I0tehn9wHOUINc/fu5 tdI2OnON34bVxXMQ1rojBQEfgi5Lsz4CXUl2x1tbeglTKJMKn2CYovLNd5Gz2Jfyvvd8 yw== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2na91bmh16-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 24 Oct 2018 18:05:26 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w9OH5KEb017292; Wed, 24 Oct 2018 13:05:25 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint2.akamai.com with ESMTP id 2n7ypv9jj3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 24 Oct 2018 13:05:24 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 24 Oct 2018 13:05:23 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1365.000; Wed, 24 Oct 2018 13:05:23 -0400 From: "Salz, Rich" To: Patrick McManus CC: Mike Bishop , "" Thread-Topic: [TLS] Multi-CDN and ESNI Thread-Index: AQHUavoI2p9P3cl/z0GLHKPS/8dcY6Utm5kAgAEF84A= Date: Wed, 24 Oct 2018 17:05:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.12.0.181014 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.55] Content-Type: multipart/alternative; boundary="_000_BDC6F39510014B3FB1BFCB7A5CC7824Aakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-24_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=727 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810240143 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-24_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=720 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810240143 Archived-At: Subject: Re: [TLS] Multi-CDN and ESNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 17:05:33 -0000 --_000_BDC6F39510014B3FB1BFCB7A5CC7824Aakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayBNaWtlIG1lbnRpb25lZCB0aGUgb25lIGtleWluZyByZWNvcmQ7IEkgd2FzIHN1Z2dl c3RpbmcgbXVsdGlwbGUga2V5aW5nIHJlY29yZHMuICBCdXQgcGVyaGFwcyB0aGUgb25lIGtleSBy ZWNvcmQgaXMgYSBrZXktd3JhcHBpbmcga2V5PyAgTmVlZCB0byB0aGluayBhYm91dCB0aGF0IGEg Yml0Lg0K --_000_BDC6F39510014B3FB1BFCB7A5CC7824Aakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <4369C8CA9D0BB244A5801F0ED961FB5E@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIE1p a2UgbWVudGlvbmVkIHRoZSBvbmUga2V5aW5nIHJlY29yZDsgSSB3YXMgc3VnZ2VzdGluZyBtdWx0 aXBsZSBrZXlpbmcgcmVjb3Jkcy4mbmJzcDsgQnV0IHBlcmhhcHMgdGhlIG9uZSBrZXkgcmVjb3Jk IGlzIGEga2V5LXdyYXBwaW5nIGtleT8mbmJzcDsgTmVlZCB0byB0aGluayBhYm91dCB0aGF0IGEg Yml0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BDC6F39510014B3FB1BFCB7A5CC7824Aakamaicom_-- From nobody Wed Oct 24 14:04:33 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B744128B14 for ; Wed, 24 Oct 2018 14:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ducksong.com header.b=jRoQYzzQ; dkim=pass (2048-bit key) header.d=outbound.mailhop.org header.b=WMMFwq+U Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZUpOwy2c1kj for ; Wed, 24 Oct 2018 14:04:28 -0700 (PDT) Received: from outbound2n.ore.mailhop.org (outbound2n.ore.mailhop.org [54.186.218.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E90C126CC7 for ; Wed, 24 Oct 2018 14:04:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540415067; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=EbRbq9ud0+2MgcY9BprEdRnpaSTqNKC6VCd9TdIcE9i5IJ0glAy7gpUbMV7jB3gbSDMoh0GAnqKuH P+lyZp2PrA2gIusa0FOU+vnI52LYApj4uGvzQRx2siSCbjSzUQg/mjT/P1DDfZp4ZkWzbMkRHm2E+6 OXfHv9TQ+13CNSR7b46nJMoJM75+yyNtJOrAUHHYvoBl6KedBcGSFAyKkqmPbiTpi0Tw7xVZPRZ4fB vR0WkDeHpxlVgD/M1QdTK1PnHwwxnKH7XHlUotBuNFChWNdaldpt8usAY7/WaPDnT4zHZrWYtcrpfw xdhJJe3XL48KI5zLzXl4w7QOIUJYSaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:dkim-signature:dkim-signature:from; bh=wcMHFR7wKmnz4PsxhOSpf7lA/WRScG+KayJsMlRMDu8=; b=DKPiCu2fiSggcDd66YmZaZfiEJ3F0ToDdCBdnsCU5/JcFKLVd848JsCgnu7BQ1GsoTAjCrvZGFQ5i On74iwyJ+byPq/OEyV9+K5aiA6AT80GcZd1t5jBRYq2I5RaxzsPjFqPGLPzS0iqxmpS78HMzbwQ1zn nsNz8Ja1OxmloD198Zb8i3MAbOpmRo/hdAV5zNOHthmhWdiEyNIIBB3GKbXC0mRsfjhFqgZ+mvSSTu VK0IsJYCd264P19Qzhkg8LlksvNASSDR8vyXd1sSZ+QpiwLT6wC0PD22YxY+Vp4OCQ2CUd3/Qfnmeb yAlPvYYwVx2tOi8J71KMF/P3w6GWHjg== ARC-Authentication-Results: i=1; outbound2.ore.mailhop.org; spf=pass smtp.mailfrom=ducksong.com smtp.remote-ip=209.85.210.42; dmarc=none header.from=ducksong.com; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ducksong.com; s=duo-1537391512170-ea99bbb3; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=wcMHFR7wKmnz4PsxhOSpf7lA/WRScG+KayJsMlRMDu8=; b=jRoQYzzQDovleYq/Gpy00xyTZOJ9/Pu7H3RZv2U4YbXPWmgY8kqkUY3lN7hcsqTHnsB0iFLgPjDSb CLHHXDRmKd5nZUdVUkGM3GaqHLNdh4fN0F21nrqfcHnUYY2x8CYyC/6Nyy5NQofYGNvo6vSosrTunv UIhjeTYgjp1INBA4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=wcMHFR7wKmnz4PsxhOSpf7lA/WRScG+KayJsMlRMDu8=; b=WMMFwq+UQSBEAN6b8hwGCiAJNC2voNxhiy3xeA2AUH+lxqc301AjS0+sfDm56mWkiPa1f8o8gDyFo XOpnx0rCLFvnkJGP+aQskCAqHhm+XTVQ08OR0atXRbhl4FkhSbtj607YWG4EV7lLaVHI4itS7X3sli 3RWgJL/lUfY9/ApdnrUgnptNTc3KR5uD5h1MUD4B0MLmGh0rjq7gPEbYhfp1T9bf55gBovfih1pGsg 9/afl8RaVssCLx6jVVhr30rg+8tLbwr2zC/L8WFS60RllMB/T/yHpSZE7+QKkBTUrIKCx7hT+8TDiF /dov6jWT16XxSw7GGsL7ydthtZxsSEQ== X-MHO-RoutePath: bWNtYW51cw== X-MHO-User: 636da507-d7d0-11e8-a630-335f030b21f2 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 209.85.210.42 X-Mail-Handler: DuoCircle Outbound SMTP Received: from mail-ot1-f42.google.com (unknown [209.85.210.42]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 636da507-d7d0-11e8-a630-335f030b21f2; Wed, 24 Oct 2018 21:04:26 +0000 (UTC) Received: by mail-ot1-f42.google.com with SMTP id k9so6481513otl.10 for ; Wed, 24 Oct 2018 14:04:25 -0700 (PDT) X-Gm-Message-State: AGRZ1gKuwpsMBF30AFDvCThW+0tnPv1ZPk3yuWozdGKxLvDSe2Vv003X /qMczUmvqRkiUHRgMIR6rTzRMEwsFoUMbBrLtLw= X-Google-Smtp-Source: AJdET5e84GfeEl44xTlrTaRisISuVte9JTafLrCd3/fonnSTfJG/l+qByw1vWJd9jWKvZDhVI1Hbp8triFAUGumUa0M= X-Received: by 2002:a9d:32b:: with SMTP id 40mr2482165otv.5.1540415065434; Wed, 24 Oct 2018 14:04:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Patrick McManus Date: Wed, 24 Oct 2018 17:04:14 -0400 X-Gmail-Original-Message-ID: Message-ID: To: "Patrick R. McManus" Cc: Nick Sullivan , "Salz, Rich" , "" Content-Type: multipart/alternative; boundary="000000000000c831830578ffd4ed" Archived-At: Subject: Re: [TLS] Multi-CDN and ESNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 21:04:32 -0000 --000000000000c831830578ffd4ed Content-Type: text/plain; charset="UTF-8" Here's a PR on one way to skin this cat. https://github.com/ekr/draft-rescorla-tls-esni/pull/104/files I hope to work this into a PR.. my first attempt wasn't very readable, but >>> I'll try again tomorrow. >>> >>> -P >>> >>> >>> --000000000000c831830578ffd4ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Here's a PR on one way to skin this c= at.


=
I hope to = work this into a PR.. my first attempt wasn't very readable, but I'= ll try again tomorrow.
<= div>
-P


--000000000000c831830578ffd4ed-- From nobody Wed Oct 24 17:19:40 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B781294D7 for ; Wed, 24 Oct 2018 17:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsXYTg55i6_a for ; Wed, 24 Oct 2018 17:19:36 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA2701294D0 for ; Wed, 24 Oct 2018 17:19:36 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id p24-v6so1927158qtq.0 for ; Wed, 24 Oct 2018 17:19:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=pgGhLN3sxEltQp74uC9qQm9Ku72RPBnSuiHNUg1YDE0=; b=CVakkT9NEW9AlpyOwJoe5QpjNpCY9zKnM9/sj47O8aVYijJfy1DbCnIhUailpHcDht Z6kJORwtsnOf34jcczdwH7yL39hqCXm20lvAeFsaTGZzHoma2TOUz8smNXu0/lpnx2ca PcG2KsD3xzV0fprMFakyfr9dN7e4l3mTxAlpg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=pgGhLN3sxEltQp74uC9qQm9Ku72RPBnSuiHNUg1YDE0=; b=e3x7B1ume+1XNaK8wP5ZzCPL79XNJSsuUMKOjC6I0f18P9KnNlIs3A4/rqn5Hl1yLx 7ORUNH4RKRPJ5dVu6mQGC0oQM7t+Tc8x11y78o4Z0mHiezN1001NWt9U/fFYwyGw/H5W B7xQcpyGeSW20OFQekjXGe99cd3cfzG7c8plUrT1b2erzXIijhzB/vAgEdGPW4XSQxlo BWo8ElscjdlwXvdZ79XGLrgkP50FoT0Ih488ITNGfHE3MgDTO9Wkptl3i6vjGcJ6I6B7 fz6LgEPP9o08lFaj4WKC9GG+4Tt8qNp3ilazHOMMFqhboFHIcgKE6Ql/DDOf6S4dBKRw 7blA== X-Gm-Message-State: AGRZ1gI9unX/poAnV4XmJvYevH0pCl3C0dkvSpnabJEUuX7IFsnGoknq M2ksRBHwNkXnLdsuKvMLuAUITmE7rj0= X-Google-Smtp-Source: AJdET5fl2Cw+14jwbUKsy+tjN1GxynzADZlroqcSIWNfcBVrhDUtQu7ygpi2L6WPBnWJLxFPTdiXaQ== X-Received: by 2002:ac8:40c2:: with SMTP id f2-v6mr4721047qtm.218.1540426775613; Wed, 24 Oct 2018 17:19:35 -0700 (PDT) Received: from [172.16.0.18] ([96.231.224.191]) by smtp.gmail.com with ESMTPSA id z188-v6sm4464925qkz.66.2018.10.24.17.19.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Oct 2018 17:19:34 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: Date: Wed, 24 Oct 2018 20:19:33 -0400 To: tls@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [TLS] kicking off charter revision discussion X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 00:19:39 -0000 With the finalization of TLS 1.3 behind us, it is time to consider = rechartering the working group to address ongoing and emerging issues in = this space. Below is a proposal for the new charter text to get this = discussion going before we meet in Bangkok. We plan to have a 20 minute = discussion section on the charter in one of the upcoming TLS WG meeting = sessions. If you have objections to what is written, please raise them = to the list; we will track them with issues in the newly created GH repo = [0]. If you feel something is omitted, please also bring it to the list = but also feel free to suggest edits via issues/PRs in that repo. Thanks, Chris, Joe, and Sean [0] https://github.com/tlswg/wg-materials/tree/master/charter.=20 Proposed Charter Text The TLS (Transport Layer Security) working group was established in 1996 = to standardize a 'transport layer' security protocol. The basis for the = work was SSL (Secure Socket Layer) v3.0 [RFC6101]. The TLS working group = has completed a series of specifications that describe the TLS protocol = v1.0 [RFC2246], v1.1 [RFC4346], v1.2 [RFC5346], and v1.3 [RFC8446], and = DTLS (Datagram TLS) v1.0 [RFC4347] and v1.2 [RFC6347], as well as = extensions to the protocols and ciphersuites. The working group aims to achieve three goals. First, to develop DTLS = 1.3, in a way that draws upon the design, analysis, and engineering = effort put into TLS 1.3. Specifically, the protocol should exhibit the = following features, in no particular order:=20 - Encrypt as much of the handshake and datagram packets as possible to reduce the amount of observable data to both passive and active attackers. - Reduce handshake latency and aim for one roundtrip for a full handshake and one or zero roundtrip for repeated handshakes without compromising current security features. - Use cryptographic algorithms equivalent to those used in TLS 1.3. The second working group goal is to improve protocol extensibility, = usability, and deployability, e.g., GREASE, Delegated Credentials, = Certificate Compression, and Exported Authenticators. These working = group items will include a focus on privacy properties of (D)TLS, with a = particular emphasis on the following: - Encrypt the ClientHello SNI (Server Name Indication) and other application-sensitive extensions, such as ALPN (Applications-Layer Protocol Negotiation). - Identify and mitigate other (long-term) user tracking or = fingerprinting vectors enabled by TLS deployments and implementations. - Consider additional privacy-preserving mechanisms, e.g., consistent application traffic padding. - Develop privacy-friendly profiles describing recommended usage of (D)TLS for generic use. Protocol-specific profiles are out of scope.=20= The third goal is to maintain current and previous version of the (D)TLS = protocols as well as to specify general best practices for use of = (D)TLS, extensions to (D)TLS, and cipher suites. This includes = recommendations as to when a particular version should be deprecated. = Changes or additions to older versions of (D)TLS whether via extensions = or ciphersuites are discouraged and require significant justification to = be taken on as work items.=20 With these objectives in mind, the TLS WG will also place a priority in = minimizing gratuitous changes to (D)TLS.= From nobody Thu Oct 25 10:48:06 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16E12130E05 for ; Thu, 25 Oct 2018 10:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9Zj-QY_AKVi for ; Thu, 25 Oct 2018 10:48:03 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12F82130DFC for ; Thu, 25 Oct 2018 10:48:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 333151D9C6A; Thu, 25 Oct 2018 10:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxonNxeetdtN; Thu, 25 Oct 2018 10:48:00 -0700 (PDT) Received: from [10.0.1.10] (unknown [47.144.151.242]) by c8a.amsl.com (Postfix) with ESMTPA id D88D41C51EC; Thu, 25 Oct 2018 10:47:59 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Megan Ferguson In-Reply-To: <20181019145942.GD19309@kduck.kaduk.org> Date: Thu, 25 Oct 2018 10:48:01 -0700 Cc: Martin Thomson , RFC System , Tim Dierks , Eric Rescorla , Christopher Wood , Joseph Salowey , sean+ietf@sn3rd.com, dave_thompson_2@comcast.net, "" Content-Transfer-Encoding: quoted-printable Message-Id: <584E08A3-8C78-4593-8F7A-C8EA9F7576F7@amsl.com> References: <20181019062451.15CF9B8011D@rfc-editor.org> <20181019145942.GD19309@kduck.kaduk.org> To: Benjamin Kaduk X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [TLS] [Technical Errata Reported] RFC5246 (5535) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 17:48:05 -0000 Hi Ben, We recommend using =93Rejected=94 with a verifier note to capture the = necessary information. =20 That way a reader knows that the =93error=94 has been considered and a = conclusion reached versus leaving in =93Reported=94. Thank you. RFC Editor/mf On Oct 19, 2018, at 7:59 AM, Benjamin Kaduk wrote: > It does feel like an artifact of the times, yes. > So I am not sure if there is a better option than "Rejected" (or, I = guess, > leave in "Reported" indefinitely). >=20 > -Ben >=20 > On Fri, Oct 19, 2018 at 05:34:48PM +1100, Martin Thomson wrote: >> An artifact of the times more than an error methinks? The document >> does also say: "Currently, DSA [DSS] may only be used with SHA-1." in >> the context of talking about use of different hash algorithms for = DSA. >>=20 >> Good thing that we obsoleted that RFC and removed DSA, now we don't >> have to worry about it any more... ;) Seriously though, I don't know >> the process for dealing with valid criticisms of features that have >> been obsoleted. Hold For Document Update seems very wrong, so we can >> rule that out at least. >>=20 >> On Fri, Oct 19, 2018 at 5:25 PM RFC Errata System >> wrote: >>>=20 >>> The following errata report has been submitted for RFC5246, >>> "The Transport Layer Security (TLS) Protocol Version 1.2". >>>=20 >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata/eid5535 >>>=20 >>> -------------------------------------- >>> Type: Technical >>> Reported by: Dave Thompson >>>=20 >>> Section: 4.7 >>>=20 >>> Original Text >>> ------------- >>> In DSA, the 20 bytes of the SHA-1 hash are run directly through = the >>> Digital Signing Algorithm with no additional hashing. ... >>>=20 >>> Corrected Text >>> -------------- >>> In DSA, the bytes of the selected hash are run directly through = the >>> Digital Signing Algorithm with no additional hashing. ... >>>=20 >>> Notes >>> ----- >>> In 2246 and 4346 this statement (then using the less-accurate = spellings DSS and SHA) was correct because only SHA1 was used for DSA = (and ECDSA, in 4492, versus SHA1+MD5 for RSA), but 5246 changed this to = allow specifying one of several hashes, with selection constrained by = the signature_algorithms extension (if present) or CertificateRequest = field from the peer. >>>=20 >>> FIPS 186 actually defines the hashing step as part of signature = generation and verification, so it might be even better to make this = something like "For DSA, signature generation applies the selected hash = [to the contents] and then computes two values, r and s." similar to the = way the preceding paragraph of 5246 "In RSA signing" differs from the = 2246 and 4346 versions by no longer treating the hashing as separate, = but that is a bigger change to an obsoleted document, and arguably = problematic because the normative reference is FIPS 186-2; as indicated = in Appendix B on page 80, 186-3 which officially allowed DSA to use FIPS = 180-3 hashes (not only SHA-1) was released in draft before 5246 but not = finalized until after (2006-03 to 2009-06 versus 2008-08). >>>=20 >>> 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. >>>=20 >>> -------------------------------------- >>> 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 >>>=20 >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >=20 From nobody Sat Oct 27 16:17:09 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8A0130E0A; Sat, 27 Oct 2018 16:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQ7Z1Z2Rfd0e; Sat, 27 Oct 2018 16:17:04 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6414E126F72; Sat, 27 Oct 2018 16:17:04 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 6F37AB80194; Sat, 27 Oct 2018 16:16:59 -0700 (PDT) To: dave_thompson_2@comcast.net, tim@dierks.org, ekr@rtfm.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: kaduk@mit.edu, iesg@ietf.org, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20181027231659.6F37AB80194@rfc-editor.org> Date: Sat, 27 Oct 2018 16:16:59 -0700 (PDT) Archived-At: Subject: [TLS] [Errata Rejected] RFC5246 (5535) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2018 23:17:09 -0000 The following errata report has been rejected for RFC5246, "The Transport Layer Security (TLS) Protocol Version 1.2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5535 -------------------------------------- Status: Rejected Type: Technical Reported by: Dave Thompson Date Reported: 2018-10-19 Rejected by: Benjamin Kaduk (IESG) Section: 4.7 Original Text ------------- In DSA, the 20 bytes of the SHA-1 hash are run directly through the Digital Signing Algorithm with no additional hashing. ... Corrected Text -------------- In DSA, the bytes of the selected hash are run directly through the Digital Signing Algorithm with no additional hashing. ... Notes ----- In 2246 and 4346 this statement (then using the less-accurate spellings DSS and SHA) was correct because only SHA1 was used for DSA (and ECDSA, in 4492, versus SHA1+MD5 for RSA), but 5246 changed this to allow specifying one of several hashes, with selection constrained by the signature_algorithms extension (if present) or CertificateRequest field from the peer. FIPS 186 actually defines the hashing step as part of signature generation and verification, so it might be even better to make this something like "For DSA, signature generation applies the selected hash [to the contents] and then computes two values, r and s." similar to the way the preceding paragraph of 5246 "In RSA signing" differs from the 2246 and 4346 versions by no longer treating the hashing as separate, but that is a bigger change to an obsoleted document, and arguably problematic because the normative reference is FIPS 186-2; as indicated in Appendix B on page 80, 186-3 which officially allowed DSA to use FIPS 180-3 hashes (not only SHA-1) was released in draft before 5246 but not finalized until after (2006-03 to 2009-06 versus 2008-08). --VERIFIER NOTES-- As described in the reported Notes, at the time of publication, the DSA specification in force only allowed for the usage of SHA-1. So the document was correct at time of publication and an errata is not appropriate, even though subsequent events have allowed for the usage of a broader set of hash algorithms with DSA. -------------------------------------- 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 From nobody Mon Oct 29 09:30:45 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD67130DF9 for ; Mon, 29 Oct 2018 09:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=onboardsecurity-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMgGsNOQKIBA for ; Mon, 29 Oct 2018 09:30:41 -0700 (PDT) Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B18621292F1 for ; Mon, 29 Oct 2018 09:30:41 -0700 (PDT) Received: by mail-pl1-x635.google.com with SMTP id s5-v6so2429444plq.11 for ; Mon, 29 Oct 2018 09:30:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onboardsecurity-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=cA8eR2sB/W0y3FZr4Hma7+o/FCVSXAgcA6Zwnlu6kxU=; b=GQl626fzM9odtvS189xjGZ+Y3T2p8u83viFulPOLDjnEks8DKzWX1M6vwOujxM8W7I p6AfuBCs0Tr+R/Zy+RkXcBJZ211155AsqAujJXlV63ektElJoqeoTf9GFyMSUGurCS+v kaNvUdeMX8SjnempCAFBOuFLPuk7ZKUGAbdNQJzl86PSHvXe35iv+9WaNSBz3iVo3zNS SpNOfNbMPPVmh+F8ExfBrYWEiZDm3e9lSR5i7enKmtCDTO7Qx/ytqanUER4lJhnvZELv tMvpTmj7t5CoJ3ZXSvXgeTcn1h2LLBijWSbYYDNGByv2IHSNdJTuCWS2qJAC2IjKGbPT 6HbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=cA8eR2sB/W0y3FZr4Hma7+o/FCVSXAgcA6Zwnlu6kxU=; b=PeLkm+D+z6iJEpj6ySpp/XsRvRX8SRMqh21N6xx0GFAPhv9Jt38v+7LjrhT+/A6fti tI61wLkR8wMPYs5sBYERcbSWOmoBzdGqPRX1OaJebBAdTdL3albnAFnDijKFEjj9yWH9 nGzVFfuZbQyKlsSRMKdQElFM+w6NCjaiz7vAI4fLT85fhjkzGgSZNLHWrs13jMjIOIMN AjsM+m0jEOQeRQwHipjzvFnS/0R2J57l4br013U/MrT6X/00f9I9Rp8rQ3UvCQr+J4lO OB0UGJOk1zNfo2dO2Og6wXJgTxRgDbfdjv6dQQdrA4J+AMeZIod8q97ePAUOpX6r38nZ Q5cA== X-Gm-Message-State: AGRZ1gL0NKxLwtnyt+Sh5MSn0GZmxKjivXnHMeu5nAe6smSy0BqK2J8S ABRjl7Er5lh61modoALSGBt+btjBvs0= X-Google-Smtp-Source: AJdET5diWCkyqGNZXe9mXl9yTarhwPZ9WpZs86mIflzQAlNy0DQ4Nqy00GaxfrDbLS16rXBJ4+EEUg== X-Received: by 2002:a17:902:7847:: with SMTP id e7-v6mr15154485pln.104.1540830640628; Mon, 29 Oct 2018 09:30:40 -0700 (PDT) Received: from [100.72.53.212] ([216.4.53.35]) by smtp.gmail.com with ESMTPSA id x23-v6sm22118186pfh.56.2018.10.29.09.30.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Oct 2018 09:30:39 -0700 (PDT) Date: Mon, 29 Oct 2018 07:34:52 -0700 From: William Whyte To: tls@ietf.org, Sean Turner Cc: =?utf-8?Q?=E5=BC=A0_=E6=8C=AF=E9=A3=9E?= Message-ID: <086da519-3cfe-4287-9efb-f20a1c9d4c72@Spark> In-Reply-To: References: X-Readdle-Message-ID: 086da519-3cfe-4287-9efb-f20a1c9d4c72@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5bd735ad_7c3dbd3d_110cc" Archived-At: Subject: Re: [TLS] kicking off charter revision discussion X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 16:30:44 -0000 --5bd735ad_7c3dbd3d_110cc Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I=E2=80=99m happy to submit the draft as it stands. I think it=E2=80=99s = covered by the recharter below under =E2=80=9Cmaintain=E2=80=9D the spec,= though perhaps we should suggest that this is changed to =E2=80=9Cmainta= in and, as necessary, extend=E2=80=9D. Cheers, William On Oct 24, 2018, 8:20 PM -0400, Sean Turner , wrote: > With the finalization of TLS 1.3 behind us, it is time to consider rech= artering the working group to address ongoing and emerging issues in this= space. Below is a proposal for the new charter text to get this discussi= on going before we meet in Bangkok. We plan to have a 20 minute discussio= n section on the charter in one of the upcoming TLS WG meeting sessions. = If you have objections to what is written, please raise them to the list;= we will track them with issues in the newly created GH repo =5B0=5D. If = you feel something is omitted, please also bring it to the list but also = feel free to suggest edits via issues/PRs in that repo. > > Thanks, > Chris, Joe, and Sean > > =5B0=5D https://github.com/tlswg/wg-materials/tree/master/charter. > > Proposed Charter Text > > The TLS (Transport Layer Security) working group was established in 199= 6 to standardize a 'transport layer' security protocol. The basis for the= work was SSL (Secure Socket Layer) v3.0 =5BR=46C6101=5D. The TLS working= group has completed a series of specifications that describe the TLS pro= tocol v1.0 =5BR=46C2246=5D, v1.1 =5BR=46C4346=5D, v1.2 =5BR=46C5346=5D, a= nd v1.3 =5BR=46C8446=5D, and DTLS (Datagram TLS) v1.0 =5BR=46C4347=5D and= v1.2 =5BR=46C6347=5D, as well as extensions to the protocols and ciphers= uites. > > The working group aims to achieve three goals. =46irst, to develop DTLS= 1.3, in a way that draws upon the design, analysis, and engineering effo= rt put into TLS 1.3. Specifically, the protocol should exhibit the follow= ing features, in no particular order: > > - Encrypt as much of the handshake and datagram packets as > possible to reduce the amount of observable data to both > passive and active attackers. > - Reduce handshake latency and aim for one roundtrip for a full > handshake and one or zero roundtrip for repeated handshakes > without compromising current security features. > - Use cryptographic algorithms equivalent to those used in TLS 1.3. > > The second working group goal is to improve protocol extensibility, usa= bility, and deployability, e.g., GREASE, Delegated Credentials, Certifica= te Compression, and Exported Authenticators. These working group items wi= ll include a focus on privacy properties of (D)TLS, with a particular emp= hasis on the following: > > - Encrypt the ClientHello SNI (Server Name Indication) and other > application-sensitive extensions, such as > ALPN (Applications-Layer Protocol Negotiation). > - Identify and mitigate other (long-term) user tracking or fingerprinti= ng > vectors enabled by TLS deployments and implementations. > - Consider additional privacy-preserving mechanisms, e.g., consistent > application traffic padding. > - Develop privacy-friendly profiles describing recommended usage of > (D)TLS for generic use. Protocol-specific profiles are out of scope. > > The third goal is to maintain current and previous version of the (D)TL= S protocols as well as to specify general best practices for use of (D)TL= S, extensions to (D)TLS, and cipher suites. This includes recommendations= as to when a particular version should be deprecated. Changes or additio= ns to older versions of (D)TLS whether via extensions or ciphersuites are= discouraged and require significant justification to be taken on as work= items. > > With these objectives in mind, the TLS WG will also place a priority in= minimizing gratuitous changes to (D)TLS. > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > TLS mailing list > TLS=40ietf.org > https://www.ietf.org/mailman/listinfo/tls --5bd735ad_7c3dbd3d_110cc Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
I=E2=80=99m happ= y to submit the draft as it stands. I think it=E2=80=99s covered by the r= echarter below under =E2=80=9Cmaintain=E2=80=9D the spec, though perhaps = we should suggest that this is changed to =E2=80=9Cmaintain and, as neces= sary, extend=E2=80=9D.

Cheers,

William
On Oct 24, 2018= , 8:20 PM -0400, Sean Turner <sean=40sn3rd.com>, wrote:
With the finalization of TLS 1= .3 behind us, it is time to consider rechartering the working group to ad= dress ongoing and emerging issues in this space. Below is a proposal for = the new charter text to get this discussion going before we meet in Bangk= ok. We plan to have a 20 minute discussion section on the charter in one = of the upcoming TLS WG meeting sessions. If you have objections to what i= s written, please raise them to the list; we will track them with issues = in the newly created GH repo =5B0=5D. If you feel something is omitted, p= lease also bring it to the list but also feel free to suggest edits via i= ssues/PRs in that repo.

Thanks,
Chris, Joe, and Sean

=5B0=5D https://github.com/tlswg/wg-materials/tree/master/charter.

Proposed Charter Text

The TLS (Transport Layer Security) working group was established in 1996 = to standardize a 'transport layer' security protocol. The basis for the w= ork was SSL (Secure Socket Layer) v3.0 =5BR=46C6101=5D. The TLS working g= roup has completed a series of specifications that describe the TLS proto= col v1.0 =5BR=46C2246=5D, v1.1 =5BR=46C4346=5D, v1.2 =5BR=46C5346=5D, and= v1.3 =5BR=46C8446=5D, and DTLS (Datagram TLS) v1.0 =5BR=46C4347=5D and v= 1.2 =5BR=46C6347=5D, as well as extensions to the protocols and ciphersui= tes.

The working group aims to achieve three goals. =46irst, to develop DTLS 1= .3, in a way that draws upon the design, analysis, and engineering effort= put into TLS 1.3. Specifically, the protocol should exhibit the followin= g features, in no particular order:

- Encrypt as much of the handshake and datagram packets as
possible to reduce the amount of observable data to both
passive and active attackers.
- Reduce handshake latency and aim for one roundtrip for a full
handshake and one or zero roundtrip for repeated handshakes
without compromising current security features.
- Use cryptographic algorithms equivalent to those used in TLS 1.3.
=
The second working group goal is to improve protocol extensibility, usabi= lity, and deployability, e.g., GREASE, Delegated Credentials, Certificate= Compression, and Exported Authenticators. These working group items will= include a focus on privacy properties of (D)TLS, with a particular empha= sis on the following:

- Encrypt the ClientHello SNI (Server Name Indication) and other
application-sensitive extensions, such as
ALPN (Applications-Layer Protocol Negotiation).
- Identify and mitigate other (long-term) user tracking or fingerprinting=
vectors enabled by TLS deployments and implementations.
- Consider additional privacy-preserving mechanisms, e.g., consistent
application traffic padding.
- Develop privacy-friendly profiles describing recommended usage of
= (D)TLS for generic use. Protocol-specific profiles are out of scope.

The third goal is to maintain current and previous version of the (D)TLS = protocols as well as to specify general best practices for use of (D)TLS,= extensions to (D)TLS, and cipher suites. This includes recommendations a= s to when a particular version should be deprecated. Changes or additions= to older versions of (D)TLS whether via extensions or ciphersuites are d= iscouraged and require significant justification to be taken on as work i= tems.

With these objectives in mind, the TLS WG will also place a priority in m= inimizing gratuitous changes to (D)TLS.
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
TLS mailing list
TLS=40ietf.org
https://www.ietf.org/mailman/listinfo/tls
--5bd735ad_7c3dbd3d_110cc-- From nobody Mon Oct 29 21:29:13 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A97E61277BB for ; Mon, 29 Oct 2018 21:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KI3qnRUiyveP for ; Mon, 29 Oct 2018 21:29:10 -0700 (PDT) Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D48F5126CB6 for ; Mon, 29 Oct 2018 21:29:09 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.22/8.16.0.22) with SMTP id w9U4Li9h046031; Mon, 29 Oct 2018 21:29:08 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : from : subject : date : references : cc : to : message-id; s=20180706; bh=5tH8fLId+kxGXKTwZT2k390mayBvk6F41AeL/njhSRU=; b=iZvodjvT6EXIwvLs1LxHBM+zIQ0gq4OAfe+kyIvdLdv+D5LXaq8LkcieWb3SV/7AMbYn o1/tdS3zPwTbmj7YUHOvDO4YAV9LQaXpuWOGmxwXAvF4ckXpVLp0KdIKprmM2WZRLTHs SGSbBjd8B9tCBqe/9xGoqpkspmovk99QUvAG2VMaOrpATkRukzSHk5jvDWkyirKdrh1a 1edygMrn+s9tWTpBnF10ddWeZH2Uqv+EkXFRH/usdbHYvv8TXNOtQAhMDxlOc4yjxK9z 1D558DI86urxBNhTxrAWniOYL+ysrUtdhI82IJd0yJhKYsjJqY4n4DqLo/hAEDuSDVTI IQ== Received: from mr2-mtap-s01.rno.apple.com (mr2-mtap-s01.rno.apple.com [17.179.226.133]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 2ncpp7n9rg-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 29 Oct 2018 21:29:08 -0700 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_ONh5VW9mblUNy5XKEwRFWQ)" Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by mr2-mtap-s01.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PHE00EF99SJFT90@mr2-mtap-s01.rno.apple.com>; Mon, 29 Oct 2018 21:29:07 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PHE001008WPTA00@nwk-mmpp-sz12.apple.com>; Mon, 29 Oct 2018 21:29:07 -0700 (PDT) X-Va-A: X-Va-T-CD: 3ab6cfbeef9fe0930bcbd49ada4d0cd2 X-Va-E-CD: 319a9bb5eb523d3898d065872d8c8c28 X-Va-R-CD: fb34b86a35da7bf35833e617179c9384 X-Va-CD: 0 X-Va-ID: fe46ef3a-9eb0-4128-900d-ef08d5ce18d5 X-V-A: X-V-T-CD: 69f1e59f2adbdec55bfbab028fbe6668 X-V-E-CD: 319a9bb5eb523d3898d065872d8c8c28 X-V-R-CD: fb34b86a35da7bf35833e617179c9384 X-V-CD: 0 X-V-ID: 9be0d191-307f-49fb-a6c3-e9d485a2818b Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PHE00D009JPZL00@nwk-mmpp-sz12.apple.com>; Mon, 29 Oct 2018 21:29:03 -0700 (PDT) Authentication-results: corp.apple.com; spf=softfail smtp.mailfrom=cawood@apple.com; dmarc=quarantine header.from=apple.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-10-30_02:,, signatures=0 Received: from [17.234.99.167] (unknown [17.234.99.167]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PHE00DGZ9SELO40@nwk-mmpp-sz12.apple.com>; Mon, 29 Oct 2018 21:29:03 -0700 (PDT) Sender: cawood@apple.com From: Christopher Wood Date: Mon, 29 Oct 2018 21:29:02 -0700 References: <153947914453.12405.8323044666882273582.idtracker@ietfa.amsl.com> To: tls@ietf.org Message-id: X-Mailer: Apple Mail (2.3499.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-30_02:, , signatures=0 Archived-At: Subject: [TLS] Fwd: New Version Notification for draft-wood-tls-ticketrequests-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 04:29:12 -0000 --Boundary_(ID_ONh5VW9mblUNy5XKEwRFWQ) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable This updated version of the ticket requests draft incorporates feedback = we received in Montreal. Specifically, it removes the post-handshake = request and response messages in favor of a simpler mechanism by which = clients indicate their desired ticket count in a CH extension. Time = permitting, we=E2=80=99d like a few minutes to discuss the latest = changes and gauge WG interest in the draft. Thanks, Chris (chair hat off) > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-wood-tls-ticketrequests-01.txt > Date: October 13, 2018 at 6:05:44 PM PDT > To: Christopher Wood , David Schinazi = , Tommy Pauly , "Christopher A. = Wood" >=20 >=20 > A new version of I-D, draft-wood-tls-ticketrequests-01.txt > has been successfully submitted by Christopher A. Wood and posted to = the > IETF repository. >=20 > Name: draft-wood-tls-ticketrequests > Revision: 01 > Title: TLS Ticket Requests > Document date: 2018-10-13 > Group: Individual Submission > Pages: 6 > URL: = https://www.ietf.org/internet-drafts/draft-wood-tls-ticketrequests-01.txt > Status: = https://datatracker.ietf.org/doc/draft-wood-tls-ticketrequests/ > Htmlized: = https://tools.ietf.org/html/draft-wood-tls-ticketrequests-01 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-wood-tls-ticketrequests > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-wood-tls-ticketrequests-01 >=20 > Abstract: > TLS session tickets enable stateless connection resumption for > clients without server-side per-client state. Servers vend session > tickets to clients, at their discretion, upon connection > establishment. Clients store and use tickets when resuming future > connections. Moreover, clients should use tickets at most once for > session resumption, especially if such keying material protects = early > application data. Single-use tickets bound the number of parallel > connections a client may initiate by the number of tickets received > from a given server. To address this limitation, this document > describes a mechanism by which clients may specify the desired = number > of tickets needed for future connections. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 --Boundary_(ID_ONh5VW9mblUNy5XKEwRFWQ) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable This = updated version of the ticket requests draft incorporates feedback we = received in Montreal. Specifically, it removes the post-handshake = request and response messages in favor of a simpler mechanism by which = clients indicate their desired ticket count in a CH extension. Time = permitting, we=E2=80=99d like a few minutes to discuss the latest = changes and gauge WG interest in the draft.

Thanks,
Chris = (chair hat off)

Begin forwarded = message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-wood-tls-ticketrequests-01.txt
Date: = October 13, 2018 at 6:05:44 PM = PDT
To: = Christopher Wood <cawood@apple.com>, = David Schinazi <dschinazi@apple.com>, Tommy Pauly <tpauly@apple.com>, = "Christopher A. Wood" <cawood@apple.com>


A new version = of I-D, draft-wood-tls-ticketrequests-01.txt
has been = successfully submitted by Christopher A. Wood and posted to the
IETF repository.

Name: = draft-wood-tls-ticketrequests
Revision: 01
Title:= = TLS Ticket Requests
Document date: = 2018-10-13
Group: Individual Submission
Pages:= = 6
URL: =            https://www.ietf.org/internet-drafts/draft-wood-tls-ticketreque= sts-01.txt
Status: =         https://datatracker.ietf.org/doc/draft-wood-tls-ticketrequests/=
Htmlized:       https://tools.ietf.org/html/draft-wood-tls-ticketrequests-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-wood-tls-ticketrequ= ests
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-wood-tls-ticketreques= ts-01

Abstract:
=   TLS session tickets enable stateless connection resumption = for
  clients without server-side per-client = state.  Servers vend session
  tickets to = clients, at their discretion, upon connection
=   establishment.  Clients store and use tickets when = resuming future
  connections.  Moreover, = clients should use tickets at most once for
=   session resumption, especially if such keying material = protects early
  application data. =  Single-use tickets bound the number of parallel
=   connections a client may initiate by the number of tickets = received
  from a given server.  To = address this limitation, this document
=   describes a mechanism by which clients may specify the = desired number
  of tickets needed for future = connections.




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

The IETF = Secretariat


= --Boundary_(ID_ONh5VW9mblUNy5XKEwRFWQ)-- From nobody Mon Oct 29 21:40:37 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6365E128A5C for ; Mon, 29 Oct 2018 21:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmapFURkWOaQ for ; Mon, 29 Oct 2018 21:40:33 -0700 (PDT) Received: from nwk-aaemail-lapp03.apple.com (nwk-aaemail-lapp03.apple.com [17.151.62.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC1681288BD for ; Mon, 29 Oct 2018 21:40:33 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.22/8.16.0.22) with SMTP id w9U4bQpI027257 for ; Mon, 29 Oct 2018 21:40:33 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : from : subject : message-id : date : to; s=20180706; bh=leGNmALjMhLxKhMvFMbHC+mc9CbfnymQzKm3rSaImHw=; b=JnKwd045eflQ+t1jXBcJo8xCVma3unqFyk/lTgheqnParIizMKbDp2jmy7XvITzAQKhd ao6rBqy49dsXsqGp91RVN9Kn5iywCq2sOwHmYJ7oZuUhZEN0+N694x5AcB0FzL6fWV40 GV3QTKRohUH5+3fVlV/6RJGpuc8b70fvPnf/gih705eQecGebt2Z/IRTNn9RaNBn3AVL 9rTwE4eKGfx5zm+4xfuAaO5wtM5AqWQuPyXkFaqiJUFlRWuQBas4aw7p11UTayvJ/n/U mnPpJbPEP5N8uyZmKCSaH2TLg6MDMpQaeQth2jDtDCowWDXEneCzD1I3yRkPl7gQzIkN iw== Received: from mr2-mtap-s02.rno.apple.com (mr2-mtap-s02.rno.apple.com [17.179.226.134]) by nwk-aaemail-lapp03.apple.com with ESMTP id 2ncmj8fnxj-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 29 Oct 2018 21:40:33 -0700 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_ImtHSi2Clg3Pld4OBBNTIg)" Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by mr2-mtap-s02.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PHE00BWBABGME70@mr2-mtap-s02.rno.apple.com> for tls@ietf.org; Mon, 29 Oct 2018 21:40:28 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PHE00M00A0BXA00@nwk-mmpp-sz12.apple.com> for tls@ietf.org; Mon, 29 Oct 2018 21:40:28 -0700 (PDT) X-Va-A: X-Va-T-CD: 3ab6cfbeef9fe0930bcbd49ada4d0cd2 X-Va-E-CD: d5a51d424836bd8c0987f7bf91454e0b X-Va-R-CD: 81733f82cc66be250b8269c96b9f7c53 X-Va-CD: 0 X-Va-ID: c12bba9b-109a-4a23-a985-6343f3b3e372 X-V-A: X-V-T-CD: 69f1e59f2adbdec55bfbab028fbe6668 X-V-E-CD: d5a51d424836bd8c0987f7bf91454e0b X-V-R-CD: 81733f82cc66be250b8269c96b9f7c53 X-V-CD: 0 X-V-ID: ddb19520-01b5-4fe2-8953-a099daf2b14a Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PHE00J009UHXN00@nwk-mmpp-sz12.apple.com> for tls@ietf.org; Mon, 29 Oct 2018 21:40:26 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-10-30_02:,, signatures=0 Received: from [17.234.99.167] (unknown [17.234.99.167]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PHE00DWYABDLO40@nwk-mmpp-sz12.apple.com> for tls@ietf.org; Mon, 29 Oct 2018 21:40:26 -0700 (PDT) Sender: cawood@apple.com From: Christopher Wood Message-id: Date: Mon, 29 Oct 2018 21:40:25 -0700 To: tls@ietf.org X-Mailer: Apple Mail (2.3499.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-30_02:, , signatures=0 Archived-At: Subject: [TLS] External PSK importers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 04:40:35 -0000 --Boundary_(ID_ImtHSi2Clg3Pld4OBBNTIg) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable To resurrect the discussion around external PSKs and TLS 1.3, I wrote = down the importer-based design Ekr and I discussed [1]. = https://datatracker.ietf.org/doc/draft-wood-tls-external-psk-importer/ = Time permitting, I=E2=80=99d like to present this in BKK. It would be = useful to compare and contrast this against David=E2=80=99s Universal = PSK draft [2]. Thanks, Chris (chair hat off) [1] = https://mailarchive.ietf.org/arch/msg/tls/FKB5oNxTVoIh59I3q9epHk6Q1Uw = [2] https://datatracker.ietf.org/doc/draft-davidben-tls-universal-psk/ = --Boundary_(ID_ImtHSi2Clg3Pld4OBBNTIg) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable
To resurrect the discussion around external PSKs and TLS 1.3, = I wrote down the importer-based design Ekr and I discussed = [1].

  =  https://datatracker.ietf.org/doc/draft-wood-tls-external-psk-im= porter/

Time= permitting, I=E2=80=99d like to present this in BKK. It would be useful = to compare and contrast this against David=E2=80=99s Universal PSK draft = [2].

Thanks,
Chris (chair hat off)

[1] https://mailarchive.ietf.org/arch/msg/tls/FKB5oNxTVoIh59I3q9epH= k6Q1Uw
[2] https://datatracker.ietf.org/doc/draft-davidben-tls-universal-p= sk/

= --Boundary_(ID_ImtHSi2Clg3Pld4OBBNTIg)-- From nobody Mon Oct 29 21:50:08 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3C21277BB for ; Mon, 29 Oct 2018 21:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOQVI0pOxDzS for ; Mon, 29 Oct 2018 21:50:04 -0700 (PDT) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B059D126CB6 for ; Mon, 29 Oct 2018 21:50:04 -0700 (PDT) Received: by mail-ot1-x336.google.com with SMTP id f24so4146553otl.5 for ; Mon, 29 Oct 2018 21:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=70VWO6gYfzA47yGBFPyNohYWpSO4/aKAI8DSTeIXs3g=; b=Tbiz4amT4Zrmz5uA/KIiH67An7DXEzrJuhpTJNAtnS6GYgrb9BV6r7YjxAAY0MHmKR h14luxullliTD0aP3J/A2bVzMyq2pg/3q101pmkrZwZo751Pvh6OXZ6rfj/TDX+Gw9n4 wX0maFjoydW7YULXCpyATgZGiSkMwgDcWiAQhEJX1giyu4NsUIKdM4+PUMqwBO9dQqMB dtk5p6Lli1AHjIXvibRwK+1QePgBBY+sgeg7H9S17kLiHp4R6JM7E8VepcTEDtDgr5vS j/UqUXglJTpAWhlC4IVVhjp08T7Ly5cS/SCTu6zS1llJMLWwMHeHQv7r0pf6ciZdp0X5 n9uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=70VWO6gYfzA47yGBFPyNohYWpSO4/aKAI8DSTeIXs3g=; b=T6aE2GTy0Ho051aVfXtSQBcbyAGznVd7JgXiqv5BdgnPkpr8W8vKisUUoBfwOxAUrn nvFgHo0qMIiOmb0YCFjSoJCtFAJSrgNF7gR1sr0OHNapIjvdYXmcF8KSSjXSv/M6BGBE JnFRJTGkfi1Pjzi75w34RpBDbOttQ4H3O9IW9M3HFHiEuT2aNW6BB47/BncWmCLJ4TIy l7HetZymojnJEkaWUeJ+FKsyhjj3VBP7VJse6km9QAs/MSIXo1E4itFQUbk/ZlapFwe+ rehH137fJKGu2zj4fljzfEjFr/m+9Z6OeAKTOdFSRrXoveyK//zZEgxp74H2XlLrTQ9V cgwA== X-Gm-Message-State: AGRZ1gKlxq3nvZuZJa/Tp10VIsz2o3FER+ATZEeG7iFOiLvnnrBH2ujf 3Z2vrpd6DfUiCQOFbhrvAWSTjkNs910RcKCcK+xsAiwx X-Google-Smtp-Source: AJdET5fXdVe/d9wC8hybxeCVmv/3yqqwnGPjKPwBr/usI1rQG/lPZEun875VX9NN7ZROsR7cIWVn2K+z3U4lkgc9ngE= X-Received: by 2002:a9d:250d:: with SMTP id k13mr8556477otb.142.1540875003745; Mon, 29 Oct 2018 21:50:03 -0700 (PDT) MIME-Version: 1.0 References: <153947914453.12405.8323044666882273582.idtracker@ietfa.amsl.com> In-Reply-To: From: Martin Thomson Date: Tue, 30 Oct 2018 15:49:54 +1100 Message-ID: To: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [TLS] TLS message limits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 04:50:07 -0000 There is an ongoing discussion on the QUIC issue tracker that might benefit from some attention here. https://github.com/quicwg/base-drafts/issues/1834 Of most interest here is that there is no mechanism by which a TLS endpoint can limit the size of handshake messages. This wasn't a problem prior to TLS 1.3, renegotiation notwithstanding, but if an endpoint needs to buffer a 16Mb message it will probably be unhappy. And many TLS implementations buffer. Knowing where short of 16Mb is safe to send is tricky. Right now, all we do is rely on the natural pressure to keep tickets small and the fact that tickets are pure overhead to keep things under control, but it's a hole that is a little irritating to leave unpatched. Of secondary concern for QUIC and DTLS, but not TLS, is the total amount of data that can be sent in handshake messages. If that data arrives out of order, it would be nice to bound the amount of memory that is apportioned for receiving and reassembling handshake messages. I mention this only because the same solution might be used to fix both problems. (I was motivated to post this after reading the ticket requests draft from Chris, which we should publish. That draft doesn't run really cause this problem, but it made me think that 255 tickets might make a bit of a mess if sent all at once.) From nobody Mon Oct 29 21:56:16 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5EE51288BD for ; Mon, 29 Oct 2018 21:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uU5dM2lXRPiY for ; Mon, 29 Oct 2018 21:56:11 -0700 (PDT) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B177B126CB6 for ; Mon, 29 Oct 2018 21:56:11 -0700 (PDT) Received: by mail-oi1-x22b.google.com with SMTP id f21-v6so6119206oig.1 for ; Mon, 29 Oct 2018 21:56:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=L53mFm8G+zQ8FZGKDXf4VdesFcAkAmpqkuECUpr8fbw=; b=T9rW12H0YXihQYc8SU6EEHaeVxXU9OqBOa2tYdqRf7ukF5EoUP1PGus0ekAo5epLHS hLwiB5VGrsRexc10T0P3sg1LaBzwUcX2FBCCncNgD49wM91NeocRPd8CQhrutOOqRqcE 35cFvnCYAL210KWTtHTDQP6fQnpi4KY0YkdeDks7gKwTP9RaJaIcpEyJyxJsYAsaBwqh AAgSjBEBWPYhL5zdG/gV5HsvujqqTMmM7XZfhnwPjzIybNjSoLiggl+VGjh2RfkxhMh2 R31g7v0aYPPdSR8Ak6tHN0VNJ5WoSK8Sp0XNRpcXEW4eR4XBkY8uUaWqjPn/WN9zGET/ c5iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=L53mFm8G+zQ8FZGKDXf4VdesFcAkAmpqkuECUpr8fbw=; b=hpBsYQninSsQRbdJC7BN+/CT6rZrNwb9ll1EOiVG4xAycp3cnT1AE0XNrUAb5xCFI6 bor5+DirPD5JG4WEGRPXTBtxmtyn8hzy/Is2PKS00qdM0CrzrPmpyu7KX7a3MfvobAqf 6vyoByFzVfCBHvI1FXtOrLMtJJTJbKgSr8dESDEWO/ynjsWJYtsFmj3VqwH6bJgZ0kab 2h0Di2n4uxp3STmEb4MclQ3wuXW5bNJkN3yaxJLXqFDdcocbjf0SEJKbIitka+S2P3qB ZqPOL2PUw7WqDBkMJ96lpJ8/IbZdYoqAx0KA2TDC8aVSavyEsiN7SjBrVVC8BMX+fY+t s13g== X-Gm-Message-State: AGRZ1gKxajQ8kBEFYe5XTqLj5BF3lMhtxyvEyz4SnXD5CbQHtc6Mohwo kHw7kYOGMlgxbT+QYU8kBl37UJxeqh5IClGxrQU= X-Google-Smtp-Source: AJdET5df2WmBAjYjk2qnuQB6mIF39oDvwwIhQFEoQoeAb6562IfZRULecVmt9jUVdcsXLvjpce1kixntcd6iaYv1OYI= X-Received: by 2002:aca:c792:: with SMTP id x140-v6mr9523345oif.129.1540875370993; Mon, 29 Oct 2018 21:56:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Martin Thomson Date: Tue, 30 Oct 2018 15:56:01 +1100 Message-ID: To: Chris Wood Cc: "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] External PSK importers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 04:56:14 -0000 Happy to talk about this. Based on a quick reading, a few notes: You should do something more concrete with the label parameter. Keep in mind that both client and server need to agree on a use for this, so my initial intuition to put the server identity might not work, but it could be a start. The problem being that how the client identifies the server might not be something it shares with the server. You equivocate regarding the hash to use. If we're going to make this solid, then we need to follow good hygiene and say that each imported PSK needs to be used with just one hash function. You equivocate again more than I like about TLS 1.2. How about you reserve a label specifically for TLS 1.2 and feed the PSK through the expand function using that label? On Tue, Oct 30, 2018 at 3:41 PM Christopher Wood wrote: > > To resurrect the discussion around external PSKs and TLS 1.3, I wrote dow= n the importer-based design Ekr and I discussed [1]. > > https://datatracker.ietf.org/doc/draft-wood-tls-external-psk-importer/ > > Time permitting, I=E2=80=99d like to present this in BKK. It would be use= ful to compare and contrast this against David=E2=80=99s Universal PSK draf= t [2]. > > Thanks, > Chris (chair hat off) > > [1] https://mailarchive.ietf.org/arch/msg/tls/FKB5oNxTVoIh59I3q9epHk6Q1Uw > [2] https://datatracker.ietf.org/doc/draft-davidben-tls-universal-psk/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Mon Oct 29 23:26:24 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE40128CE4 for ; Mon, 29 Oct 2018 23:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlcuTG9E5A-p for ; Mon, 29 Oct 2018 23:26:21 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB52B1277D2 for ; Mon, 29 Oct 2018 23:26:20 -0700 (PDT) Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx12.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1gHNTl-0002Y4-Sm for tls@ietf.org; Tue, 30 Oct 2018 07:26:19 +0100 Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1gHNTh-00016s-28 for tls@ietf.org; Tue, 30 Oct 2018 02:26:13 -0400 Received: (qmail 27675 invoked from network); 30 Oct 2018 06:26:11 -0000 Received: from unknown (HELO [192.168.1.100]) (Authenticated-user:_huitema@huitema.net@[172.56.42.225]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 30 Oct 2018 06:26:11 -0000 To: tls@ietf.org References: From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <1a5c2d42-4232-b7b1-27a0-97c2b033129c@huitema.net> Date: Mon, 29 Oct 2018 23:26:08 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: 168.144.250.232 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: ham X-AntiSpamCloud-Outgoing-Evidence: Combined (0.06) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5hSHBHevpYEr3vmqaNlsJ7J602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO5IcVwV4jjVcAOtIXxgohGFVMZsRZacTbJPGp/MBC6BxfJxiO36Yc0k+k9UtbGRyMUh5 mNm/WjPqhYqCeBiCKwzwNnO0oYiZjOnC1Xa7kCO2ejk40iyx8hQPmbkJabHvUPvRa7MR4hgRIg8N 1QlY4G4/E7SMkAew92PUfpE24E7riSGt4Ko2sv7hY6P0Yu3OA+AIcPc2JG++Fh0y/kogNkMJ0464 etNXHOU+5Kb0QuG3bATPP9eeLWC5kDweN7crsXBXvrLBlKCVRjjdPbjQ4HmidG0pg2HLuLsP3mPp isElTs5Ex5aNZlcgVQFtAhrEij3dKxLhoxcmaInYbR5vlqETd+klAX+KFYkIxu6zxdn+X2XX9bIs GDSYq5OAASmskVIcMSgqtcKbU9La+AHiCFB9vuYMeDoXsMJDD9CZFW2DHXeua4usuyudZl7ZJWmg 5a0jiD6XqsJZtjQxlyCdseyUYJbyy1lVJ6nYOoLd75iYvy7NvAbxEgZSsI+HSLa0cdJmUD1qAvsw 1abLZ0+OiLlk354Leo8WHhg9Xcph2esmZk4AVtnYApSiFQp1w3dnUoiPn/2xNqt6sQVacVXeY6AU 1zqm/evfkH8cHl25+qKdJvWZ9M/O6eVqbri1Q0O8/x2vWOKTBJk2Pbgs7SLYxsD2v881ctH3ieoG WLsGKrL9Pp155dhZNw2MvR7uLOodM3G5BnVj6tDKYf18xfK0O5gaJ/Nk40anfxYE/e+AHCqTw6nI oDr0sXUZ7YZoZ/GZ+u+WjISfXGa/P6JeP9Rx/xr6vvsamCqhsCKWQTQWW5aiOYN2LGYOY+RZZ70I EJvMPP9qwM7RXpJS8RjTdyh2j5BSM6Vge5/tyLofFHTUZzjpzRBCCyVCnQKBwcrUTMoPTDRj9D8H LKHAKpPGP8EPnuBvlPE9yn4+7R7hw716lUpV X-Report-Abuse-To: spam@quarantine6.antispamcloud.com Archived-At: Subject: Re: [TLS] External PSK importers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 06:26:22 -0000 On 10/29/2018 9:56 PM, Martin Thomson wrote: > You should do something more concrete with the label parameter. Keep > in mind that both client and server need to agree on a use for this, > so my initial intuition to put the server identity might not work, but > it could be a start. The problem being that how the client identifies > the server might not be something it shares with the server. There is also a privacy issue with the external identifiers. For session tickets, this is solved by only using a given resume ticket once, but that's harder with external PSK. -- Christian Huitema From nobody Tue Oct 30 04:07:53 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B4D128B14 for ; Tue, 30 Oct 2018 04:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbzadSWUmFaq for ; Tue, 30 Oct 2018 04:07:49 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16F06126CC7 for ; Tue, 30 Oct 2018 04:07:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 98DF7300AA5 for ; Tue, 30 Oct 2018 07:07:46 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id eSucH97HcRID for ; Tue, 30 Oct 2018 07:07:45 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-71-178-45-35.washdc.fios.verizon.net [71.178.45.35]) by mail.smeinc.net (Postfix) with ESMTPSA id A954D300A48; Tue, 30 Oct 2018 07:07:45 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Russ Housley In-Reply-To: <1a5c2d42-4232-b7b1-27a0-97c2b033129c@huitema.net> Date: Tue, 30 Oct 2018 07:07:46 -0400 Cc: IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: <7DE67484-DF67-47CF-9934-CB44F61D1EA0@vigilsec.com> References: <1a5c2d42-4232-b7b1-27a0-97c2b033129c@huitema.net> To: Christian Huitema X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [TLS] External PSK importers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 11:07:51 -0000 > On Oct 30, 2018, at 2:26 AM, Christian Huitema = wrote: >=20 > On 10/29/2018 9:56 PM, Martin Thomson wrote: >=20 >> You should do something more concrete with the label parameter. Keep >> in mind that both client and server need to agree on a use for this, >> so my initial intuition to put the server identity might not work, = but >> it could be a start. The problem being that how the client = identifies >> the server might not be something it shares with the server. >=20 > There is also a privacy issue with the external identifiers. For = session > tickets, this is solved by only using a given resume ticket once, but > that's harder with external PSK. Christian: Proclaiming that you have access to a particular external PSK may reveal = that you as part of a group. I do not see a way to completely avoid = this because the PSK is input to the key schedule at the very top. = Thus, there is no key that could be used to encrypt it. The importer described by Chris does provide some obfuscation of the = base key identity, but an observer will be able to see each of the key = identifiers that are derived, even if they cannot tell which one goes = with a particular external PSK. Padding with bogus key identifiers does = not help either as the group membership may be revealed by watching = which imported key identifier get selected by the server. Russ= From nobody Tue Oct 30 04:37:40 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2178612D4EC for ; Tue, 30 Oct 2018 04:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=fmmRbpy8; dkim=pass (1024-bit key) header.d=ericsson.com header.b=ZFbItKJz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f29J2nMStqGv for ; Tue, 30 Oct 2018 04:37:36 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C3FB128B14 for ; Tue, 30 Oct 2018 04:37:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1540899454; x=1543491454; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0NW58IXZV6He24YvB/6qjAHBPV37bd/7+bvqL3PpBr0=; b=fmmRbpy8YH9IAGrLv5kA4K+2LeWH250GhF68bRYQemzVjItkwjCqJ5ZU1aONFoHr L5p2wJ8eM49rzQ8fKg6XqIGpV+1xXqE9Zdy/tD4iAcPLi7QFlIO2QBxhMaNkHTQ0 13bIPGhm7507pVu/7JGNFK/b02iVeBI/3kV/2UcdBL4=; X-AuditID: c1b4fb2d-425ff7000000434d-e3-5bd8427ec134 Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 4C.26.17229.E7248DB5; Tue, 30 Oct 2018 12:37:34 +0100 (CET) Received: from ESESSMR505.ericsson.se (153.88.183.127) by ESESSMB501.ericsson.se (153.88.183.119) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 30 Oct 2018 12:37:34 +0100 Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESSMR505.ericsson.se (153.88.183.127) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 30 Oct 2018 12:37:34 +0100 Received: from EUR04-VI1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 30 Oct 2018 12:37:34 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0NW58IXZV6He24YvB/6qjAHBPV37bd/7+bvqL3PpBr0=; b=ZFbItKJz/U93WI/ehvu66+FV4pOLl3oLYdieJhc5gu54v7jpfAemU3CnT0huzNS1vpSa7ActZKwIzWshDYAfWU/TIcfed3fEvu4+SuqLVULA5e65INiwrAvdMry1pwByMW8vhX51AuF2tJ+DeAwTZv3U9xClCgSiWiUVwRDGWrw= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.166.22) by HE1PR07MB4441.eurprd07.prod.outlook.com (20.176.167.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.16; Tue, 30 Oct 2018 11:37:33 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::fcb5:ca45:9e56:1910]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::fcb5:ca45:9e56:1910%2]) with mapi id 15.20.1294.018; Tue, 30 Oct 2018 11:37:33 +0000 From: John Mattsson To: Martin Thomson , "" Thread-Topic: [TLS] TLS message limits Thread-Index: AQHUcAwZY+ts8iPxHUC4mOe4KMqEPqU3uowA Date: Tue, 30 Oct 2018 11:37:32 +0000 Message-ID: <8550C52C-9A63-4946-B5A9-C76C5DF87516@ericsson.com> References: <153947914453.12405.8323044666882273582.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.11.0.180909 x-originating-ip: [192.176.1.81] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB4441; 6:/+f8Cbx63vTAROSbeJW6cZJXQJ95+2+E4lmm7ZM/VRE/mmd4OtZ8y7gIm0GFjaQ3lZpka5mkO/p8S8MInlF5UR/hpyuExPBQr01t5wSPsWENTR6kdivUrP69zAruYyjZi47a1XeguTAuefnKTmW+NuZSqW1b8J4w9D2vf/ZB32Qc4BpHOfNRCeAKuIinRjcZnrbrDSa3jl65SErdbnXYzLboKsOOLEgLWfCmIGkriweQgBY9WL8Ws1rRDM8+ZtZbNlrUhf8asaC2jw1kDE4CvIas2yWJU2ehd+5PSNDA9I3afb9CvjVCFxZ1ZtSK18hMS6IRSB/vURRW+CMgBWzdvMGLUGHLZyOEyWKDP9HK6EQva8iAdKvtBaXELzBfUPVUqnALGE9y96PMjnpTKJbpuCDZE8W71RlmI9ITrqYqms+pM6wbe4s2GmxSbj9bZYg/ufHtlzRVTwzMpiofSpx/CQ==; 5:Ra23hAEb/zn4x6ja1iP+wF/MeVyubepr2c/WGV2oPAp+xofe7iDxqqM0ciQkn8XsA4cq8dVqwekbwTCqi5SmC7WlcO9CtB0QO0IdQFJqwE1trMPGbrVz04Y79U898GuNLUTYBuFqZ7i3ecB52gQKMbw0KP8HuKusV/XRevruy1g=; 7:XTNLFOCMt02KHFdkisC8QhTmk8YBz1u50J01YzENBDUt+ySTsSPJcmtM08WwT+mmwwTJq8pGL+IrEzz+So5gZ88AcwLcY3suGilQQ8g7UMn0St/Zsg23sq+KvSx9omEFJ7+VpMpFr6Y7O2LgzeRCXQ== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 5b53cdfe-7073-4bf6-0f2e-08d63e5c150a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB4441; x-ms-traffictypediagnostic: HE1PR07MB4441: authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(85827821059158); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231382)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:HE1PR07MB4441; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB4441; x-forefront-prvs: 08417837C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(346002)(396003)(39860400002)(136003)(13464003)(189003)(199004)(36756003)(53936002)(66066001)(82746002)(106356001)(966005)(105586002)(5250100002)(7736002)(14454004)(2906002)(305945005)(2900100001)(15650500001)(39060400002)(76176011)(68736007)(8936002)(8676002)(81166006)(81156014)(86362001)(99286004)(256004)(102836004)(53546011)(26005)(6506007)(33656002)(6116002)(3846002)(25786009)(478600001)(476003)(11346002)(44832011)(14444005)(486006)(2616005)(186003)(83716004)(71190400001)(71200400001)(58126008)(5660300001)(6246003)(6306002)(97736004)(110136005)(316002)(6436002)(446003)(6512007)(6486002)(229853002)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4441; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: U1uF//j21VHUdDaGV6AONdlMU5KJeUICtZp/XsFr6jGPQWJAtGZtIZeWFPwBuIaZ0SGMFRvL8oKfBHzdTbE80dWvyYA+1AV13qYrL3OnkEgLppXSXl+3CWQh1AP1qbvgTjU2gaDQLmVG8hio4in6arWDZyK4SM+WYEBj3u6QFQyhFwQ+MWifBZtPUfxqXbS2EfuUX8+7/oeVQLY0BDtrKVAzJAi48hRczm1xuePYWrXmmu+zUgzA4WVpZwpXRBA3VtmbBCTiz+RsZ7DDJmjpG6DUt6ae+JxKvAQAved5wVImGYqWGArGFffw8XeCWFzubAsLTHWCtPUDtIHIxc82wX5S3HE2QvLUuIi8TmBg3tM= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5b53cdfe-7073-4bf6-0f2e-08d63e5c150a X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2018 11:37:32.8376 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4441 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMKsWRmVeSWpSXmKPExsUyM2J7uW6d041og9Y+BYtrZ/4xWnw638Xo wOSxc9Zddo8lS34yBTBFcdmkpOZklqUW6dslcGXM+HmcqWCORMXnL+9ZGxjPiHcxcnJICJhI TF48namLkYtDSOAIo8SjmbMZIZxvjBIPds9jhXOWr73FBuEsYZI4tmk/M4jDIjCBWeLj1WnM EJkpTBKv/ryHGvCIUeJN/1cmkDVsAgYSc/c0sIHYIgJ+Escn3GEGsYUFVCUmtC5j72LkAIqr Sby+7gFRYiSxeFUTWDkLUMnlawvZQWxeAXuJzk29UGccZ5TYsvMT2BxOgUCJndN+gNmMAmIS 30+tAdvLLCAucevJfCaIVwUkluw5zwxhi0q8fPyPFcQWFdCXmP+ggxUiriBxbMZKFghbVuLS /G6wZyQErrFJLDwxGWqQrsSHqVOhBvlK3Os5wQZRBHTRs+9z2SESWhI/Dk6CuihWorV1OtSG bIl5M5dC1XhLrF/zmXkCo/EsJMfOAgYGs4CmxPpd+hBhD4nd/w+xQNiKElO6H7LPAgeGoMTJ mU9YFjCyrmIULU4tLs5NNzLWSy3KTC4uzs/Ty0st2cQITCoHt/zW3cG4+rXjIUYBDkYlHt4b OjeihVgTy4orcw8xSnAwK4nwujsChXhTEiurUovy44tKc1KLDzFKc7AoifPqrdoTJSSQnliS mp2aWpBaBJNl4uCUamBcavFQQH5iu7Pa23V1E/l11epzb82Rr7s254mo6fNptx91GwduYqg+ K3Whvunn3PJymeo3b91WyH8sbb+hOG/HochnGqfVKz/ctbnMkjB3XeXtVGdm0WtJ/czXnFym HpgVm5x46vtHjxCTsrgLghZFBRcPNTt/WuD3r335qVecAvPVn6xpTWJUYinOSDTUYi4qTgQA 3LmsECYDAAA= Archived-At: Subject: Re: [TLS] TLS message limits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 11:37:39 -0000 Pk9mIHNlY29uZGFyeSBjb25jZXJuIGZvciBRVUlDIGFuZCBEVExTLCBidXQgbm90IFRMUywgaXMg dGhlIHRvdGFsIGFtb3VudCBvZiBkYXRhIHRoYXQgY2FuIGJlIHNlbnQgaW4gaGFuZHNoYWtlIG1l c3NhZ2VzLiAgDQoNClRoZSB0b3RhbCBhbW91bnQgb2YgZGF0YSBzZW50IGluIHRoZSBUTFMgaGFu ZHNoYWtlIGlzIHF1aXRlIGEgYmlnIGNvbmNlcm4gd2hlbiBUTFMgaXMgdXNlZCBpbiBFQVAtVExT LiBNYW55IGF1dGhlbnRpY2F0b3IgKGFjY2VzcyBwb2ludCkgaW1wbGVtZW50YXRpb25zIHdpbGwg ZHJvcCB0aGUgRUFQIHNlc3Npb24gaWYgaXQgaGFzbid0IGZpbmlzaGVkIGFmdGVyIDQwIC0gNTAg cGFja2V0cyBvciBhcHByb3hpbWF0ZWx5IDYwIGtCLiAyNTUgdGlja2V0cyB3b3VsZCBtYWtlIG1h bnkgRUFQLVRMUyBzZXNzaW9uIHRvIGZhaWwsIGJ1dCB0aGUgc3VnZ2VzdGVkIG1lY2hhbmlzbSB3 aGVyZSB0aGUgY2xpZW50IGluZGljYXRlcyB0aGUgZGVzaXJlZCBudW1iZXIgb2YgdGlja2V0cyBz ZWVtcyBnb29kLg0KDQpDaGVlcnMsDQpKb2huDQoNCu+7vy0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBUTFMgPHRscy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgTWFydGlu IFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4NCkRhdGU6IFR1ZXNkYXksIDMwIE9j dG9iZXIgMjAxOCBhdCAwNTo1MA0KVG86ICJUTFNAaWV0Zi5vcmciIDx0bHNAaWV0Zi5vcmc+DQpT dWJqZWN0OiBbVExTXSBUTFMgbWVzc2FnZSBsaW1pdHMNCg0KVGhlcmUgaXMgYW4gb25nb2luZyBk aXNjdXNzaW9uIG9uIHRoZSBRVUlDIGlzc3VlIHRyYWNrZXIgdGhhdCBtaWdodA0KYmVuZWZpdCBm cm9tIHNvbWUgYXR0ZW50aW9uIGhlcmUuDQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFz ZS1kcmFmdHMvaXNzdWVzLzE4MzQNCg0KT2YgbW9zdCBpbnRlcmVzdCBoZXJlIGlzIHRoYXQgdGhl cmUgaXMgbm8gbWVjaGFuaXNtIGJ5IHdoaWNoIGEgVExTDQplbmRwb2ludCBjYW4gbGltaXQgdGhl IHNpemUgb2YgaGFuZHNoYWtlIG1lc3NhZ2VzLiAgVGhpcyB3YXNuJ3QgYQ0KcHJvYmxlbSBwcmlv ciB0byBUTFMgMS4zLCByZW5lZ290aWF0aW9uIG5vdHdpdGhzdGFuZGluZywgYnV0IGlmIGFuDQpl bmRwb2ludCBuZWVkcyB0byBidWZmZXIgYSAxNk1iIG1lc3NhZ2UgaXQgd2lsbCBwcm9iYWJseSBi ZSB1bmhhcHB5Lg0KQW5kIG1hbnkgVExTIGltcGxlbWVudGF0aW9ucyBidWZmZXIuICBLbm93aW5n IHdoZXJlIHNob3J0IG9mIDE2TWIgaXMNCnNhZmUgdG8gc2VuZCBpcyB0cmlja3kuICBSaWdodCBu b3csIGFsbCB3ZSBkbyBpcyByZWx5IG9uIHRoZSBuYXR1cmFsDQpwcmVzc3VyZSB0byBrZWVwIHRp Y2tldHMgc21hbGwgYW5kIHRoZSBmYWN0IHRoYXQgdGlja2V0cyBhcmUgcHVyZQ0Kb3ZlcmhlYWQg dG8ga2VlcCB0aGluZ3MgdW5kZXIgY29udHJvbCwgYnV0IGl0J3MgYSBob2xlIHRoYXQgaXMgYQ0K bGl0dGxlIGlycml0YXRpbmcgdG8gbGVhdmUgdW5wYXRjaGVkLg0KDQpPZiBzZWNvbmRhcnkgY29u Y2VybiBmb3IgUVVJQyBhbmQgRFRMUywgYnV0IG5vdCBUTFMsIGlzIHRoZSB0b3RhbA0KYW1vdW50 IG9mIGRhdGEgdGhhdCBjYW4gYmUgc2VudCBpbiBoYW5kc2hha2UgbWVzc2FnZXMuICBJZiB0aGF0 IGRhdGENCmFycml2ZXMgb3V0IG9mIG9yZGVyLCBpdCB3b3VsZCBiZSBuaWNlIHRvIGJvdW5kIHRo ZSBhbW91bnQgb2YgbWVtb3J5DQp0aGF0IGlzIGFwcG9ydGlvbmVkIGZvciByZWNlaXZpbmcgYW5k IHJlYXNzZW1ibGluZyBoYW5kc2hha2UgbWVzc2FnZXMuDQpJIG1lbnRpb24gdGhpcyBvbmx5IGJl Y2F1c2UgdGhlIHNhbWUgc29sdXRpb24gbWlnaHQgYmUgdXNlZCB0byBmaXgNCmJvdGggcHJvYmxl bXMuDQoNCihJIHdhcyBtb3RpdmF0ZWQgdG8gcG9zdCB0aGlzIGFmdGVyIHJlYWRpbmcgdGhlIHRp Y2tldCByZXF1ZXN0cyBkcmFmdA0KZnJvbSBDaHJpcywgd2hpY2ggd2Ugc2hvdWxkIHB1Ymxpc2gu ICBUaGF0IGRyYWZ0IGRvZXNuJ3QgcnVuIHJlYWxseQ0KY2F1c2UgdGhpcyBwcm9ibGVtLCBidXQg aXQgbWFkZSBtZSB0aGluayB0aGF0IDI1NSB0aWNrZXRzIG1pZ2h0IG1ha2UgYQ0KYml0IG9mIGEg bWVzcyBpZiBzZW50IGFsbCBhdCBvbmNlLikNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NClRMUyBtYWlsaW5nIGxpc3QNClRMU0BpZXRmLm9yZw0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMNCg0K From nobody Tue Oct 30 08:00:01 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D8C130E00 for ; Tue, 30 Oct 2018 07:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.172 X-Spam-Level: X-Spam-Status: No, score=-1.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZ5fqWyOF9z7 for ; Tue, 30 Oct 2018 07:59:55 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E030A130DC2 for ; Tue, 30 Oct 2018 07:59:54 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.23/8.16.0.23) with SMTP id w9UEr2J8016196; Tue, 30 Oct 2018 14:59:54 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type; s=jan2016.eng; bh=BpBqLWh6DZJ1j4MliAO3e8516DyCIWZ9xaRwNYa0jJo=; b=fzTJhzZi4PqDWVPzrKY002sW0eMvBpsPFvVA3UtxzjJbIfJTTyCh84jQHs2oNcq7Onfo WBieLWZB9Mj0Q183CBsGInRR8GuqrkpbfcSFiRwHtf86+4thXHdGJy2zPstZLn69LyAW 7b+Wm5Wr8fo4SwDD+4jw8D1qnceqAQinyaoWgxjuaEnwI+WZDPnjTvwBgOplQMagpO5a +P8/G+ZzfvJIrliFzBGVf3pqhlAFmNUugL+SDiEldA1SMnR0IlbquHcL32C++PMUBiZQ rnUo8mgWd5agyD/fdCHc98cVKOwF7Mkcww9Mq4Bu9fuwbp2f3iAWq3YnwCJFEXZJjdsR /g== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2nepq98cnv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 30 Oct 2018 14:59:53 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w9UEnwaw029355; Tue, 30 Oct 2018 10:59:51 -0400 Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint3.akamai.com with ESMTP id 2nckccc5bx-1; Tue, 30 Oct 2018 10:59:51 -0400 Received: from Tereva.local (unknown [172.19.32.76]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id 7F08381394; Tue, 30 Oct 2018 14:59:51 +0000 (GMT) From: Brian Sniffen To: Sean Turner , tls@ietf.org In-Reply-To: References: Date: Tue, 30 Oct 2018 10:59:51 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-30_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810300129 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-30_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810300129 Archived-At: Subject: Re: [TLS] kicking off charter revision discussion X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 15:00:00 -0000 > The second working group goal is to improve protocol extensibility, usability, and deployability, e.g., GREASE, Delegated Credentials, Certificate Compression, and Exported Authenticators. These working group items will include a focus on privacy properties of (D)TLS, with a particular emphasis on the following: > > - Encrypt the ClientHello SNI (Server Name Indication) and other > application-sensitive extensions, such as > ALPN (Applications-Layer Protocol Negotiation). > - Identify and mitigate other (long-term) user tracking or fingerprinting > vectors enabled by TLS deployments and implementations. > - Consider additional privacy-preserving mechanisms, e.g., consistent > application traffic padding. > - Develop privacy-friendly profiles describing recommended usage of > (D)TLS for generic use. Protocol-specific profiles are out of scope. [...snip...] > With these objectives in mind, the TLS WG will also place a priority in minimizing gratuitous changes to (D)TLS. I think that last sentence is meant to prevent bright ideas from complicating---or harming---the security of TLS as defined or as implemented. But I'd like to see it as part of the second working group goal too. For example: "The second working group goal is sustain TLS' properties of confidential and authenticated communication, while also improving protocol extensibility, usability, and deployability..." The first obligation of an extension, whether it's heartbeat or key escrow, is to show that it isn't going to hurt core TLS to have it out there in the ecosystem. -Brian -- Brian Sniffen Akamai Technologies From watson@cloudflare.com Tue Oct 30 09:41:39 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F21130DC5 for ; Tue, 30 Oct 2018 09:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTySuHH5z6t9 for ; Tue, 30 Oct 2018 09:41:37 -0700 (PDT) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40F93130D7A for ; Tue, 30 Oct 2018 09:41:37 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id 131so7659648qkd.4 for ; Tue, 30 Oct 2018 09:41:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=PeTDz45qe2whQwZ2vy6Rtsg/n+PRh7UGfEthxQ7ev+M=; b=pX+h4AJC//CJyjFEcNQY8BqAWNGBkr7VWT6/j/wgX9vWvmO/+QBuQeQaRrpzjmnNDx cA9UveVk5MunmAw2JvBaGWAdaF0oaI8OglsTK9ca2itYqf7nj+HG8w6lnNUj85acBTov 68sbWEMOzt21S+nK5kK/yRmAGSrr9tIUMLcVs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=PeTDz45qe2whQwZ2vy6Rtsg/n+PRh7UGfEthxQ7ev+M=; b=mnMWSpNS8SYnJy+/FAyORlBB7qXdIrBFt2zT3tUc2wG2TqyUlPo3bu55+T3Ul9f84U Mth6vV9AI4kIMQJ0SwGnOJe1gQejNegGD98U8wZgFAxfN2rjV8mdFPh7fKsp2K26mgo1 9eSjkdg/ybmLH2ND1FoHkNf8kZ4sexLJqn+iGoEsNtIGazqhw9CuK+XSnGmnHqZtFyRU OMdUIumVl+NBCOxTTRxsf8Rt5W59mfKuRyPC/1k1k3LYw7EvEvuCbL2VfSfTrWxg/Psd BaXEZ1mIH9CU3RwyY04OMUK3ObuwXVBTIYev6S44D8ijO0Sywdc0fL52cJRs5P/LzLq4 mCrg== X-Gm-Message-State: AGRZ1gI2BMCiU40xDepiPVuRGXOCkR+ugBjQ4A3w4MgnYNGAjpZaCqA7 uipnynqaXOaP6O8zcg8GA1w9q1SD/8jw8Mb4oKR0Liof X-Google-Smtp-Source: AJdET5fFUXOXMU0ygkvXFsOJ81O1WdigDLViOoPeyNI3hMtwdvScovizUibAl92LQfFB9hllrM9dCq58Snb0axff9Uk= X-Received: by 2002:a37:b381:: with SMTP id c123mr734543qkf.346.1540917696264; Tue, 30 Oct 2018 09:41:36 -0700 (PDT) MIME-Version: 1.0 From: Watson Ladd Date: Tue, 30 Oct 2018 09:41:25 -0700 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary="000000000000ea3017057974db52" Archived-At: Subject: [TLS] Comment/question on draft-ietf-tls-subcerts-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 16:50:29 -0000 --000000000000ea3017057974db52 Content-Type: text/plain; charset="UTF-8" Dear all, Maybe I don't understand the draft, but I am reading how the signature on the Delegated Credential is computed and I don't see where we put the credential into the data that is signed. Shouldn't we include the Credential in the data over which the signature is computed? Sincerely, Watson Ladd --000000000000ea3017057974db52 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

Maybe I don't understand the dr= aft, but I am reading how the signature on the Delegated Credential is comp= uted and I don't see where we put the credential into the data that is = signed. Shouldn't we include the Credential in the data over which the = signature is computed?

Sincerely,
Watson = Ladd
--000000000000ea3017057974db52-- From nobody Tue Oct 30 11:59:24 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 006BC130DCD for ; Tue, 30 Oct 2018 11:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urTv8eeOScWE for ; Tue, 30 Oct 2018 11:59:20 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 858D4130DCB for ; Tue, 30 Oct 2018 11:59:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 8BB163A4F6; Tue, 30 Oct 2018 20:59:17 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id CnjL5lQOwJKe; Tue, 30 Oct 2018 20:59:17 +0200 (EET) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 2E35072; Tue, 30 Oct 2018 20:59:15 +0200 (EET) Date: Tue, 30 Oct 2018 20:59:14 +0200 From: Ilari Liusvaara To: Watson Ladd Cc: tls@ietf.org Message-ID: <20181030185914.GA23775@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Comment/question on draft-ietf-tls-subcerts-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 18:59:23 -0000 On Tue, Oct 30, 2018 at 09:41:25AM -0700, Watson Ladd wrote: > Dear all, > > Maybe I don't understand the draft, but I am reading how the signature on > the Delegated Credential is computed and I don't see where we put the > credential into the data that is signed. Shouldn't we include the > Credential in the data over which the signature is computed? Yeah, took a look, does not look like credential structure is included. Additionally, the text contains refernece to DelegatedCredential.scheme, which I do not see definition of (no structure contains field named "scheme"). Looks like things got borked between -01 and -02. More specifically, in this commit: commit db7339bb1f6f3b643e3358217d663273a9cabba5 Author: Christopher Patton Date: Thu Jul 26 11:17:09 2018 -0700 Drop "must-use-DC" and implement changes for draft-02 I presume the 5. and 6. in signed list should be: 5. DelegatedCredential.cred 6. DelegatedCredential.algorithm (or perhaps vice versa; they are .algorithm and .scheme right now) -Ilari From nobody Tue Oct 30 12:02:53 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5BC130E4D for ; Tue, 30 Oct 2018 12:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ji8DnesKXkt8 for ; Tue, 30 Oct 2018 12:02:38 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1793130DFD for ; Tue, 30 Oct 2018 12:02:37 -0700 (PDT) Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx65.antispamcloud.com with esmtps (TLSv1.2:AES128-SHA:128) (Exim 4.89) (envelope-from ) id 1gHZHe-0006BN-NH for tls@ietf.org; Tue, 30 Oct 2018 20:02:36 +0100 Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gHZHY-0006w3-DB for tls@ietf.org; Tue, 30 Oct 2018 15:02:32 -0400 Received: (qmail 12694 invoked from network); 30 Oct 2018 19:02:23 -0000 Received: from unknown (HELO [192.168.1.100]) (Authenticated-user:_huitema@huitema.net@[172.56.42.225]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 30 Oct 2018 19:02:22 -0000 To: Russ Housley Cc: IETF TLS References: <1a5c2d42-4232-b7b1-27a0-97c2b033129c@huitema.net> <7DE67484-DF67-47CF-9934-CB44F61D1EA0@vigilsec.com> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: Date: Tue, 30 Oct 2018 12:02:19 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <7DE67484-DF67-47CF-9934-CB44F61D1EA0@vigilsec.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 168.144.250.177 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.36) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5h0tWPG0hFaC5t1vpuAhB+5602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO5IcVwV4jjVcAOtIXxgohGFVMZsRZacTbJPGp/MBC6BxDxOulR1IrpZ94p+U7GOZIUh5 mNm/WjPqhYqCeBiCKwzwNnO0oYiZjOnC1Xa7kCO2cFBJ33PyTEulbj2AjstEIPvRa7MR4hgRIg8N 1QlY4G7x1YBTEs55LirRLgpsvCFtGgdQZXRisyliedf3wwG/i2qU6J8I9awOrPXuYGgz3WgHzKXU aRMqx/iV8P/ENaGyxxyuvB0jWb+i2PkgrNx3bPBWi14qeT2rPZ1/13TrXXs1uSg37woMz0RVvZDr sV8LYWIsgJuhzJxUTB9lxDN+Gp+9VMhAJkmEVg2pGJQCagDTBN5UXzuTNxOoOql1SHXYelGAATxC ZqJIDFYhDesXleccPtSRk0m/kQt358TQfZrY5Qx4fJOk03R5fJtf/Dv/2WNBsAy8Nv289m/zQuaH eERE5KNIYL4TOer9CexvGTH1Q9wOZPbbCAV5E1ncBg4FMv/GVRtkwgTXqRFVk6En6J28dFabfd7P HaYFsN2d6vI69TdE5SQ4dxJir0Y8rHr0CnFV4ppbCSIV+5MQOIhZDwZx+7akvXuW0uKgP4xcS0Yf /ZWJrKdeszZmTOPanuiaJuyN28CJzjT5weLgu0H3IAf6YE745piwblNU2qurWrnsn9mE+fGN0lc+ e/EYlJJDfMmwr0h6gpRCxy4/rMf5kU8byrGRBbWsaDFa8gBatH6LjIhcApHEq6VJj+GinOstdpOr kslJz3mJvCTcshirSG05iiatprOXw9FbZg9TYU/x3fBWJlKQxl5A/NUiEbAJT6hiIcrBPOkAxAXv 937MUfLd14/y82ebPziYNS9mrGeruXSJR3Z0Vju70hqF5YH+Tu89+T1gK4F4f0LxqBVlR4hU8Mt6 1NIE13FQzIlTV40= X-Report-Abuse-To: spam@quarantine6.antispamcloud.com Archived-At: Subject: Re: [TLS] External PSK importers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 19:02:51 -0000 On 10/30/2018 4:07 AM, Russ Housley wrote: >> On Oct 30, 2018, at 2:26 AM, Christian Huitema w= rote: >> >> On 10/29/2018 9:56 PM, Martin Thomson wrote: >> >>> You should do something more concrete with the label parameter. Keep= >>> in mind that both client and server need to agree on a use for this, >>> so my initial intuition to put the server identity might not work, bu= t >>> it could be a start. The problem being that how the client identifie= s >>> the server might not be something it shares with the server. >> There is also a privacy issue with the external identifiers. For sessi= on >> tickets, this is solved by only using a given resume ticket once, but >> that's harder with external PSK. > Christian: > > Proclaiming that you have access to a particular external PSK may revea= l that you as part of a group. I do not see a way to completely avoid th= is because the PSK is input to the key schedule at the very top. Thus, t= here is no key that could be used to encrypt it. You do have a shared secret, the PSK itself. In the DNS SD privacy proposal, we construct an obfuscated key identifier as base64(nonce|truncated(hash(nonce|PSK))). In the simplest form, the nonce is chosen randomly by the client, and the server has to try all available keys until it finds one that matches. We were worried about the compute cost of many trials, so we specified a "predictable nonce" set to a "rounded time" -- in our case, the most significant 24 bits of the 32 bit Unix time. The server would only have to compute the set of hashes and potential identifiers once per time interval. But that's of course a trade-off between obfuscation and compute costs. We were somewhat concerned about replay attacks, but that's a general problem with PSK. An attacker could repeat the client hello, and see whether the server's response provides information about the server identity. Hopefully, TLS 1.3 takes care of that. My point however is not to propose specific solutions, but rather to ensure that the documents that we produce acknowledges the privacy concerns with key identifiers. Once we agree that this is indeed an issue, we can debate the appropriate solution. -- Christian Huitema From nobody Tue Oct 30 13:33:54 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71DDC12D4F0 for ; Tue, 30 Oct 2018 13:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69lNEBmGTWJD for ; Tue, 30 Oct 2018 13:33:50 -0700 (PDT) Received: from smtp.ufl.edu (smtp-prod04.osg.ufl.edu [128.227.74.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6720B130DDD for ; Tue, 30 Oct 2018 13:33:49 -0700 (PDT) X-UFL-GatorLink-Authenticated: authenticated as (<>) with from 10.36.133.33 Received: from exmbxprd02.ad.ufl.edu ([10.36.133.33]) by smtp.ufl.edu (8.14.4/8.14.4/3.0.0) with ESMTP id w9UKXlvB048015 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 30 Oct 2018 16:33:47 -0400 Received: from exmbxprd23.ad.ufl.edu (128.227.145.167) by exmbxprd02.ad.ufl.edu (10.36.133.33) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 30 Oct 2018 16:33:47 -0400 Received: from exmbxprd23.ad.ufl.edu (2002:80e3:91a7::80e3:91a7) by exmbxprd23.ad.ufl.edu (2002:80e3:91a7::80e3:91a7) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 30 Oct 2018 16:33:47 -0400 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (216.32.180.47) by exmbxprd23.ad.ufl.edu (128.227.145.167) with Microsoft SMTP Server (TLS) id 15.0.1365.1 via Frontend Transport; Tue, 30 Oct 2018 16:33:47 -0400 Received: from BN6PR22MB0692.namprd22.prod.outlook.com (10.172.197.10) by BN6PR22MB0370.namprd22.prod.outlook.com (10.173.204.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1273.18; Tue, 30 Oct 2018 20:33:45 +0000 Received: from BN6PR22MB0692.namprd22.prod.outlook.com ([fe80::acca:6959:2808:8ac1]) by BN6PR22MB0692.namprd22.prod.outlook.com ([fe80::acca:6959:2808:8ac1%2]) with mapi id 15.20.1273.025; Tue, 30 Oct 2018 20:33:45 +0000 From: "Patton,Christopher J" To: "tls@ietf.org" Thread-Topic: Comment/question on draft-ietf-tls-subcerts-02 (Ilari Liusvaara) Thread-Index: AQHUcI/aZUCVqnCBXU6x4lfUqhjfFQ== Date: Tue, 30 Oct 2018 20:33:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.227.227.88] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR22MB0370; 6:nu0zmnbT1ohlbfuLU2lwX0AdIJ8qo5691Ju09marTuTt+FHZ1uIvSBoqjAnhMM1ccVhdgCbtmYr6bOdVPGYSqczqZ3zT97EjoFULQYfy0x8fzkDMv6yqZVdrpphVM+UJ01LnuumfI4xAu8yd8HEvrVDQwTXcdgWlOYo6b9wUjFzkdu+MDGA714ioIsyGIRB0ZTI1DWE6jOaomuNkXckanWnJ9K2NwzPffiN9J7P22hZn5zLD1/wtUlPms7t0OSctYi6RamR40b+/oyJcUntRIsEpr0dMdJUErOwfC4ubgvzu9vEk4sHINn6N5fMMcQw/RXtv0UB/h1AyfQ3SD/DTc1CbGW4pIufkEqW/eiXp5psz4PHqGdAxMJnMiDIcqNt2RKHQi1o8KF6YbR+CQaNIaO3gsdumPul0+9opD5ywZl52BzpUNKi7oHujEYeFXRRHox8yPxGjbgqdgPG3VXpy2A==; 5:w+/6bRN+cwwAVMkTVM7pxk/uXLH0MfTJCtpgJ6dHjNP9eXBGm8xT9H1/ykQEoIlH6+7ousDpl9KBEyuwg2/ymrYHekuvd//sHBsycbsycycInZgv0HQdBK1Sc0Yy8yr8flteCJH3kcQ8UjmSl71USrR5b5LUwTyajOckr1hXrnM=; 7:VPzVROY4X8jIU1App6+nBwteLZJZ6DQv/z1JcWNkIrWcF1xsK14LhNWaFd0FpvAptcxaVSEschtHMi6bey501LMMeJz156XthihU+qkWmB+hF3OBAvNqU915j2IOMpVxAcxRCMUBMuTqrZwacNkklA== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 2ac2972c-3405-4bfb-c2f5-08d63ea6fd53 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BN6PR22MB0370; x-ms-traffictypediagnostic: BN6PR22MB0370: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(266576461109395)(166708455590820); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231382)(944501410)(52105095)(148016)(149066)(150057)(6041310)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:BN6PR22MB0370; BCL:0; PCL:0; RULEID:; SRVR:BN6PR22MB0370; x-forefront-prvs: 08417837C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(366004)(39850400004)(346002)(376002)(199004)(189003)(5660300001)(786003)(33656002)(7696005)(68736007)(76176011)(316002)(8676002)(5250100002)(53336002)(558084003)(6436002)(99286004)(102836004)(2906002)(7736002)(6506007)(81166006)(966005)(5640700003)(2900100001)(88552002)(81156014)(74316002)(8936002)(105586002)(229853002)(1730700003)(14454004)(2501003)(75432002)(446003)(11346002)(3846002)(66066001)(106356001)(6116002)(478600001)(26005)(71200400001)(97736004)(476003)(71190400001)(486006)(6246003)(2351001)(53936002)(186003)(6606003)(256004)(86362001)(25786009)(19627405001)(6916009)(54896002)(6306002)(55016002)(9686003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR22MB0370; H:BN6PR22MB0692.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ufl.edu does not designate permitted sender hosts) x-microsoft-antispam-message-info: pQOr8fv//kJ8Puh0k6UWj9Ms9qh0TKCNTNYbRU7UQ+B4s36obrS1D6QCLQWmwBF88glVisq6h1kUG0Jc4A94FfYMoOPSqa3BMpBmP1iDKcBBL8dIOazA4Dqcwiwwj0oHMa+e+4hXWQKjsnm/AYDp/rXziVu3pegW9MALH2nzYzU4IWkCO3A+NAv9Eckjft69ZATkuZdnfrxMP+xvP+3y0MmbwWlZ6fGaL8BuY0KX3w7EgCICujzD2Err6JOGJosfRXSFHGTDRDxhQh8psl2VniWL4LCF3r8fSOK0/HWH5ux2VA74mcTkYcmnW0FVRQ8fgSJpNaJRat8BCbwKmznV3kXJyhvlSFUglRaM4dPoKmM= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR22MB0692FCEBDD972F221967F2F5C6CC0BN6PR22MB0692namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2ac2972c-3405-4bfb-c2f5-08d63ea6fd53 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2018 20:33:45.3240 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0d4da0f8-4a31-4d76-ace6-0a62331e1b84 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR22MB0370 X-OriginatorOrg: ufl.edu X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-30_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810300173 X-UFL-Spam-Level: * Archived-At: Subject: Re: [TLS] Comment/question on draft-ietf-tls-subcerts-02 (Ilari Liusvaara) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 20:33:53 -0000 --_000_BN6PR22MB0692FCEBDD972F221967F2F5C6CC0BN6PR22MB0692namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Watson, you're right! Thanks for noticing this. And thank you to Ilari f= or confirming. See PR#20 for the appropriate change: https://github.com/tlswg/tls-subcerts/pull/20 Chris Patton --_000_BN6PR22MB0692FCEBDD972F221967F2F5C6CC0BN6PR22MB0692namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Watson, you're right! Thanks for noticing this. And thank you to Il= ari for confirming. See PR#20 for the appropriate change:
https://github.com/tlswg/tls-subcerts/pull/20

Chris Patton

--_000_BN6PR22MB0692FCEBDD972F221967F2F5C6CC0BN6PR22MB0692namp_-- From nobody Tue Oct 30 14:41:59 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E172F128D09 for ; Tue, 30 Oct 2018 14:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hq0moE1qlVbx for ; Tue, 30 Oct 2018 14:41:55 -0700 (PDT) Received: from gecko.birch.relay.mailchannels.net (gecko.birch.relay.mailchannels.net [23.83.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45702127333 for ; Tue, 30 Oct 2018 14:41:55 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 67201123F85; Tue, 30 Oct 2018 21:41:54 +0000 (UTC) Received: from pdx1-sub0-mail-a21.g.dreamhost.com (unknown [100.96.36.160]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 25E34123EE3; Tue, 30 Oct 2018 21:41:54 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a21.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Tue, 30 Oct 2018 21:41:54 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Quick-Chemical: 340bb09c1ac0709e_1540935714239_321666934 X-MC-Loop-Signature: 1540935714239:126720630 X-MC-Ingress-Time: 1540935714238 Received: from pdx1-sub0-mail-a21.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a21.g.dreamhost.com (Postfix) with ESMTP id C3A15801F2; Tue, 30 Oct 2018 14:41:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=N6RurcD+w6y5VC 3BaBG4lKVH+mw=; b=LevWLZngyehFZT657RxJ2LE+/d1dhKDyPzwEplJd9ZNWFI q/Mx44ZOu2HB3B+TzKSInGsXbkvW8gg8f/1msLvIr+xyj8DqwvSDQ+vr0i1s4tB7 hrQ3XkkChjrFK6g7SmKmv3q/z7aZ6UBvHAcqpJOfUZqVZkukDBGqj3YdSKAyw= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a21.g.dreamhost.com (Postfix) with ESMTPSA id EA8ED801F5; Tue, 30 Oct 2018 14:41:51 -0700 (PDT) Date: Tue, 30 Oct 2018 16:41:48 -0500 X-DH-BACKEND: pdx1-sub0-mail-a21 From: Nico Williams To: Sean Turner Cc: tls@ietf.org Message-ID: <20181030214147.GH2486@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedriedtgdduhedtucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Archived-At: Subject: Re: [TLS] kicking off charter revision discussion X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 21:41:57 -0000 On Wed, Oct 24, 2018 at 08:19:33PM -0400, Sean Turner wrote: > Proposed Charter Text +1, but see comments below. First off, suppose we wanted to write a successor to RFC2712 for TLS 1.3, should we pursue that in the TLS WG, or KITTEN WG? I'm amenable to either, and even both. > [...] > > The second working group goal is to improve protocol extensibility, > usability, and deployability, e.g., GREASE, Delegated Credentials, > Certificate Compression, and Exported Authenticators. These working > group items will include a focus on privacy properties of (D)TLS, with > a particular emphasis on the following: Should the DANE DNSSEC chain extension be on the charter? We do need to finish it. > [...] Nico -- From nobody Tue Oct 30 18:53:54 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3591252B7 for ; Tue, 30 Oct 2018 18:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDxRkdxBbSXh for ; Tue, 30 Oct 2018 18:53:50 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85179127332 for ; Tue, 30 Oct 2018 18:53:50 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id q41-v6so15980957qtq.10 for ; Tue, 30 Oct 2018 18:53:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GRpFf955zuYrJRcHPmE5cMdUp9vo9On8qAh6riYmaJw=; b=egt/GuPmvSrGufK2j73wzFT9WEL9GLNpr2HqCHrZeqjeym7qT2lmL26lbBM9C8heey SeTSoHa0tj2LbxWuwm9V8vj716HF2Eo5Tr1rzOmoLO1d4XLHeh7fOXNhI8SXskul0L6F XmNyACSYu2XnCzktVbfyhGZEOQfy4hU+12J3A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GRpFf955zuYrJRcHPmE5cMdUp9vo9On8qAh6riYmaJw=; b=uXFQlaW//DqjkkoGVlR6cm/IskG6IrnhpPLuoXVGe/iqIc3P+oOMe6uoUd7HbYXGJR ExMsy/KKgmMyi9oFM+7AzePpmpUWc9yyV3nTh1aKpJZsn8eXQhZ6BDkNNQY6zTezkoUl 5eDXlI3fsWbJi0MTfZrL1kzg9mLe0xl4ikoyVBYTH/oy7zRxUE7AXJk8L8RffCuuKXNE EXRwpW/AQ52Scj5TmXM03tI+T0Z03prFROcNg9d1gd5bQjFiXX47VnoxQOvgscTu7rr1 P0c2HLDCfLvO1v0A/B2DE7l2mVAUjVlFPGpUHBiAceRpPhW56oug5J7u3LLUZ2SvQS+2 2Bpw== X-Gm-Message-State: AGRZ1gL7LrFiwa95QGtucsqX+0mrVQ/WcXNDbnCOeJNCjPG4mG/8KK8c v1ryRabIJol5AxLhS9soD9jUzJqUKVQ= X-Google-Smtp-Source: AJdET5cjTHsxoxDsqoYQC++lgcy+OyYB1lC/9n/w6FOlXC/JRYkM9b+xSfw+NEIf43gbyAADWWUTCg== X-Received: by 2002:a0c:d066:: with SMTP id d35mr940729qvh.233.1540950829602; Tue, 30 Oct 2018 18:53:49 -0700 (PDT) Received: from [172.16.0.18] ([96.231.224.191]) by smtp.gmail.com with ESMTPSA id v3-v6sm17409580qth.74.2018.10.30.18.53.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Oct 2018 18:53:48 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sean Turner In-Reply-To: <20181030214147.GH2486@localhost> Date: Tue, 30 Oct 2018 21:53:47 -0400 Cc: tls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <57A19984-01DC-4620-A931-693647DE9235@sn3rd.com> References: <20181030214147.GH2486@localhost> To: Nico Williams X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [TLS] kicking off charter revision discussion X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2018 01:53:52 -0000 > On Oct 30, 2018, at 17:41, Nico Williams = wrote: >=20 > On Wed, Oct 24, 2018 at 08:19:33PM -0400, Sean Turner wrote: >> Proposed Charter Text >=20 > +1, but see comments below. >=20 > First off, suppose we wanted to write a successor to RFC2712 for TLS > 1.3, should we pursue that in the TLS WG, or KITTEN WG? I'm amenable = to > either, and even both. I think both would be bad, but whether it goes in one or the other would = come down to whether there are enough people interested in doing the = work. >> [...] >>=20 >> The second working group goal is to improve protocol extensibility, >> usability, and deployability, e.g., GREASE, Delegated Credentials, >> Certificate Compression, and Exported Authenticators. These working >> group items will include a focus on privacy properties of (D)TLS, = with >> a particular emphasis on the following: >=20 > Should the DANE DNSSEC chain extension be on the charter? We do need = to > finish it. In the current charter, we already have generic text about extensions = and no specific text about the DANE DNSSEC draft though we adopted the = draft and there is a milestone for it. I prefer not to list every draft = we are working on in the charter specifically because then we have to = change the darn charter every time we want to adopt a draft. We are going to spend a lot of time discussing the DANE DNSSEC draft. = When it gets done and what is in it is certainly up for discussion. spt= From nobody Tue Oct 30 21:12:02 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 521CB1252B7 for ; Tue, 30 Oct 2018 21:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDwYUk6-fnIK for ; Tue, 30 Oct 2018 21:11:58 -0700 (PDT) Received: from cichlid.maple.relay.mailchannels.net (cichlid.maple.relay.mailchannels.net [23.83.214.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 801CA123FFD for ; Tue, 30 Oct 2018 21:11:58 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 72BEF42E36; Wed, 31 Oct 2018 04:11:57 +0000 (UTC) Received: from pdx1-sub0-mail-a65.g.dreamhost.com (unknown [100.96.20.98]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 3DB7C42E09; Wed, 31 Oct 2018 04:11:57 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a65.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Wed, 31 Oct 2018 04:11:57 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Company-Imminent: 3a304db1597140c7_1540959117346_62176054 X-MC-Loop-Signature: 1540959117346:1998110149 X-MC-Ingress-Time: 1540959117346 Received: from pdx1-sub0-mail-a65.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a65.g.dreamhost.com (Postfix) with ESMTP id F3B50805BC; Tue, 30 Oct 2018 21:11:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=FP44+98iCW6VOQ ge/YGVKi+LCjY=; b=YBr7efTk3s2DI4gh7KUmIJB28cP4ri1K0V96XM9oV9trhW lXB7flXH0cNL4od338WHDuRjJ7PhDSa6gEDY0eX/SmR0jcU1teMHS0iHNAxIj+cG RAEzg+4L3J8hM8kLc9H1Gp7tquDSdVTJGA/YwmIxGv1Y3AHS39WWhU1ApEWIU= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a65.g.dreamhost.com (Postfix) with ESMTPSA id EC398805BD; Tue, 30 Oct 2018 21:11:55 -0700 (PDT) Date: Tue, 30 Oct 2018 23:11:53 -0500 X-DH-BACKEND: pdx1-sub0-mail-a65 From: Nico Williams To: Sean Turner Cc: tls@ietf.org Message-ID: <20181031041152.GJ2486@localhost> References: <20181030214147.GH2486@localhost> <57A19984-01DC-4620-A931-693647DE9235@sn3rd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57A19984-01DC-4620-A931-693647DE9235@sn3rd.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedriedugdeilecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: Re: [TLS] kicking off charter revision discussion X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2018 04:12:00 -0000 On Tue, Oct 30, 2018 at 09:53:47PM -0400, Sean Turner wrote: > > On Oct 30, 2018, at 17:41, Nico Williams wrote: > > On Wed, Oct 24, 2018 at 08:19:33PM -0400, Sean Turner wrote: > >> Proposed Charter Text > > > > +1, but see comments below. > > > > First off, suppose we wanted to write a successor to RFC2712 for TLS > > 1.3, should we pursue that in the TLS WG, or KITTEN WG? I'm amenable to > > either, and even both. > > I think both would be bad, but whether it goes in one or the other > would come down to whether there are enough people interested in doing > the work. OK. I suspect we can get it done in KITTEN WG, where we have the Kerberos expertise, as it's really just a use of PSK in TLS, so we'd not need to extend TLS in any way. I think most here would agree. > > Should the DANE DNSSEC chain extension be on the charter? We do need to > > finish it. > > In the current charter, we already have generic text about extensions > and no specific text about the DANE DNSSEC draft though we adopted the > draft and there is a milestone for it. I prefer not to list every > draft we are working on in the charter specifically because then we > have to change the darn charter every time we want to adopt a draft. Just making sure! > We are going to spend a lot of time discussing the DANE DNSSEC draft. > When it gets done and what is in it is certainly up for discussion. Indeed. Thanks, Nico -- From nobody Tue Oct 30 21:53:01 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F44126F72 for ; Tue, 30 Oct 2018 21:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pk86uhGVazhm for ; Tue, 30 Oct 2018 21:52:56 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46A83126DBF for ; Tue, 30 Oct 2018 21:52:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1540961576; x=1572497576; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=2/fw1obGG8qdl3KUdlXKuySUqGbIegMezwgMQTRbAb8=; b=mKHRbYlpZJuho8DG1+8qQHojxH5t7jQNlP4qcGv15zeVgpDnT7qEUtDR tJ/iWBz61ZfXkKtvB+F7w/24059OXSq+OVI8gFWABbCfTQgHSjm3TFRMj AnSCqvw2fekUNWW5WCjrTVTUCKmq7UjehOQXknM12xbKLJVG0IxTFFICy ltfl6Sy7q1X8lmO07I9teSe2iyjZJItVWkDHf6InR2f4T8nSnGoYXlOBB gZ10K2b9+9qymBAhFeOu/ONJEjHdwZIKEJhjwkg/NXvPN+GpTrONTO4D+ CJIvCv8nNGU8A272ttjRo7gImGBc6Cq+f/S1eKtV+I+EfejNLO6Boxhmr A==; X-IronPort-AV: E=Sophos;i="5.54,447,1534766400"; d="scan'208";a="37457752" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.2 - Outgoing - Outgoing Received: from uxcn13-ogg-a.uoa.auckland.ac.nz ([10.6.2.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 31 Oct 2018 17:52:49 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-a.UoA.auckland.ac.nz (10.6.2.2) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 31 Oct 2018 17:52:49 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Wed, 31 Oct 2018 17:52:49 +1300 From: Peter Gutmann To: John Mattsson , Martin Thomson , "" Thread-Topic: [TLS] TLS message limits Thread-Index: AQHUcAwpWYjwWODErUqO2lnuFjqVVqU2z90AgAH7E2s= Date: Wed, 31 Oct 2018 04:52:49 +0000 Message-ID: <1540961565042.3070@cs.auckland.ac.nz> References: <153947914453.12405.8323044666882273582.idtracker@ietfa.amsl.com> , <8550C52C-9A63-4946-B5A9-C76C5DF87516@ericsson.com> In-Reply-To: <8550C52C-9A63-4946-B5A9-C76C5DF87516@ericsson.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] TLS message limits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2018 04:52:59 -0000 John Mattsson writes:=0A= =0A= >The total amount of data sent in the TLS handshake is quite a big concern= =0A= >when TLS is used in EAP-TLS. Many authenticator (access point)=0A= >implementations will drop the EAP session if it hasn't finished after 40 -= 50=0A= >packets or approximately 60 kB. =0A= =0A= It's even worse with the common EAP-over-RADIUS, where you're limited to 4k= B=0A= total size, with even that needing to be broken down into 253-byte sub-=0A= packets.=0A= =0A= Peter.=0A= From nobody Wed Oct 31 04:58:24 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382A9130DC1; Wed, 31 Oct 2018 04:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RxPJhVOV8XO; Wed, 31 Oct 2018 04:58:13 -0700 (PDT) Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DDDE12D4E7; Wed, 31 Oct 2018 04:58:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 42lRg71401zMmhT; Wed, 31 Oct 2018 12:58:11 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvoY16BL92uo; Wed, 31 Oct 2018 12:58:09 +0100 (CET) X-MtScore: NO score=0 Received: from [192.168.178.24] (mue-88-130-61-252.dsl.tropolys.de [88.130.61.252]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Wed, 31 Oct 2018 12:58:09 +0100 (CET) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: Date: Wed, 31 Oct 2018 12:58:08 +0100 Cc: Dave Plonka To: saag@ietf.org, tls@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [TLS] maprg session on Tue Nov 6, 1610-1810 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2018 11:58:15 -0000 Hi security folks! I just wanted to point you at our next maprg session in Bangkok as we = have a couple of security relevant presentations on the agenda, e.g. The Rise of Certificate Transparency and Its Implications on the = Internet Ecosystem (by Matthias W=C3=A4hlisch) Is the Web Ready for OCSP Must Staple? (Nick Sullivan) Both of these talks are at the end of the session, so maybe if = secdispatch finishes early, you maybe able to make it! The maprg session is=20 Tuesday, 6 November 2018, Afternoon Session II 1610-1810 Room Name: Chitlada 1 See you there! Mirja (chair) From nobody Wed Oct 31 11:13:13 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7323F12F1A5 for ; Wed, 31 Oct 2018 11:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ncsc.gov.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpLL0xYGXXL9 for ; Wed, 31 Oct 2018 11:13:08 -0700 (PDT) Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-cwlgbr01on0710.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe14::710]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 529BA129C6A for ; Wed, 31 Oct 2018 11:13:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=43JpoDC4jgDGpkjJZp/OwAzb/X65rnFrSydoi6Ex2NI=; b=jJIdJPes0SaStopLKJAenuCvnZ/CTYhMzHygsTSoglwfGMj7zFf6BHtWZebynBEI15yn7e03vu194L7n5Pe6LhSpzVrggSJoJI0o7k+nQPLXVEBta9zTcaprV+eQTT5vIqzqxitZOypUJhqzbwYFBYxpzQiWHkOJafGIXI5O0Ug= Received: from LOXP123MB1416.GBRP123.PROD.OUTLOOK.COM (10.166.255.18) by LOXP123MB0903.GBRP123.PROD.OUTLOOK.COM (10.166.250.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1273.21; Wed, 31 Oct 2018 18:13:04 +0000 Received: from LOXP123MB1416.GBRP123.PROD.OUTLOOK.COM ([fe80::f53d:62f8:a3d1:6993]) by LOXP123MB1416.GBRP123.PROD.OUTLOOK.COM ([fe80::f53d:62f8:a3d1:6993%3]) with mapi id 15.20.1294.021; Wed, 31 Oct 2018 18:13:04 +0000 From: Mark O To: "tls@ietf.org" Thread-Topic: Re: [TLS] WGLC for draft-ietf-tls-sni-encryption Thread-Index: AdRxQNI4EhytS2rkQ02oC4kfiidOng== Date: Wed, 31 Oct 2018 18:13:04 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Mark.O@ncsc.gov.uk; x-originating-ip: [51.140.78.31] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; LOXP123MB0903; 6:SbEHwTNIzrzbgB+QvCT3Fe25DVolaVrwpj+5TUbyHgEBYcX+kghP83noyOtai041S9E9punsD4Onq+2+oT63Pi7MAHbzgD8nd0bvINN+xX0MpeM2jkHOI3SXuqJWbAWZt7w78PuJra+HqgnrhO6L1WUn5s8qscoQVNO2y4FzVGehndrvgP3dKnSyppZr2m5F/5gCblvTXPy+Y4CVXPXbaOA3Xcn5rewzufF1JX1NNYA5sN+ejqiKSPSvNl808ncPBCgRISmqpWuH7C1PxcgRaSNhxEPrFshmNUd1mFMspSDXKcIDKGXcJbQi/CEJ5gLYoVtdBFBsY5u2YFy9nFJNDvZep5g0iAyEOcTtByHPdqP0+yh9rH0eCWC1UU88mLfz3djvOnLqYE1SQFGSFE8t0bZTPH4+NpUD88HoV/HEKEoHkMQm3kROSDwq4si1WFjHH56PotIeQF3nMIYPntnAnQ==; 5:Fhgr/VQPVasomY05CZ4MJFPxsZwflRvNi29HTNwq7VZ1YV96W+yLCoxcSwg078bN7JNCwYGpy8ErYH/VQ55Qi7ZkeQbVYp4oUosXOSiXipjdjVKmiX3YwcF+BbG+C1Jh5eUPrYXK3s/rfXqjuSBNp81+N99ShRDMtbrkI+v/6y8=; 7:+P9+HE2hg8y08TFkYkbfVlnVraK5WnPynh9ASrwGRRYJty7rAolHJyNTOebI8MLWg+Sz1PHlk1x+4+yzE/9p6ZdMv9jT1aq2mPY7itqfaS+W2w4wr6roiBC/zF1rUSHlu+mdrLtHfZemfZV/LxmS6Q== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 54108cff-de9f-445b-51a0-08d63f5c809a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:LOXP123MB0903; x-ms-traffictypediagnostic: LOXP123MB0903: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(72170088055959)(192374486261705)(158342451672863)(27231711734898)(21748063052155)(28532068793085)(190501279198761)(227612066756510); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231382)(944501410)(52105095)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:LOXP123MB0903; BCL:0; PCL:0; RULEID:; SRVR:LOXP123MB0903; x-forefront-prvs: 084285FC5C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(376002)(136003)(396003)(39850400004)(199004)(189003)(72206003)(14454004)(5630700001)(5250100002)(5660300001)(2501003)(7696005)(6916009)(478600001)(229853002)(102836004)(55236004)(14444005)(256004)(6506007)(97736004)(6116002)(3846002)(790700001)(186003)(486006)(316002)(75922002)(2900100001)(99286004)(2351001)(105586002)(86362001)(106356001)(66066001)(25786009)(33656002)(9686003)(5640700003)(54896002)(6306002)(68736007)(53936002)(55016002)(6246003)(476003)(26005)(8936002)(71200400001)(71190400001)(7736002)(74316002)(74482002)(8676002)(81156014)(81166006)(1730700003)(6436002)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:LOXP123MB0903; H:LOXP123MB1416.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ncsc.gov.uk does not designate permitted sender hosts) x-microsoft-antispam-message-info: hh/7E8JPxVUGSbd7z1LCYIk+Fq6AO6GMgz2/pJMwfdWnblvGN+e+5I4dUyfKSgE2IR0f81oinEH/lhChAIu4px3xP7+xTnlFh/t9ytPh1nqTX5I08NmVsa/NLDVNmP3UlcF5vBkwaib8s+oDnta3wj3PCBYWwx8QiBRetnAj2dB9K0AOMGfZGGf4oC5ck9MTA0Y2Y/RIHAFohOiK/ZgqnKiAHXsBG/ukg31KeRWxPLV8H2izlPlapOCdyaKFtlerObPdU4/9fCcobZFTwRodv8n7O1xeZpWLp3tYj4t6L4JxNdqR9+dwSH4DCNpH9ECw1oQtzSMpd8WeuZ6a6MVH9t5kGsPdrszoBXTpySCM03o= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_LOXP123MB14163C2F40F312AA252FDE46D3CD0LOXP123MB1416GBRP_" MIME-Version: 1.0 X-OriginatorOrg: ncsc.gov.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 54108cff-de9f-445b-51a0-08d63f5c809a X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2018 18:13:04.4900 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: LOXP123MB0903 Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-sni-encryption X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2018 18:13:12 -0000 --_000_LOXP123MB14163C2F40F312AA252FDE46D3CD0LOXP123MB1416GBRP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Some comments on draft-ietf-tls-sni-encryption-03: Section 2.3 "End-to-end alternatives" "Enterprises can deploy monitoring software to control usage of the enterpr= ises [sic] computers." At the moment enterprises have the option of installing a firewall performi= ng SNI filtering to black-list connections to certain websites. With SNI en= cryption this becomes ineffective. This draft should describe the privacy i= mpact of enterprises adopting the proposed mitigation strategy of deploying= monitoring software. Similarly, the privacy impact of introducing "opt in= " filtering of DNS and packet marking to determine QoS should be addressed.= The privacy gains of encrypting SNI need to be weighed against the privacy= losses of adopting these mitigations and at the moment this draft does not= do that. Section 3.6 "Proper security context" This section currently describes one class of solutions where there is a si= ngle TLS handshake between the client and the multiplexed server or frontin= g service, but there is another class, where the TLS handshake is between t= he client and the protected service. The text in this section should be exp= anded to encompass both classes (or it could be written as two separate sec= tions if clearer). The text should also draw out that the client and the pr= otected service are placing a great deal of trust in the fronting service, = which becomes a very powerful part of the network and hence a very attracti= ve target for attackers or malicious operators. As a suggestion, consider the following alternative text for section 3.6: We can design solutions in which the multiplexed server or a fronting servi= ce act as a relay to reach the protected service. Some of those solutions i= nvolve just one TLS handshake between the client and the multiplexed server= (or fronting service). Others involve just one TLS handshake between the c= lient and the protected service. In the first case, the master secret is verified by verifying a certificate= provided by the multiplexed server (or fronting service), but not by the p= rotected service. In the second case, the master secret is verified by veri= fying a certificate provided by the protected service. In the first case, the client is exposed to a Man-In-The-Middle attack by t= he multiplexed server (or fronting service). The client does not verify the= identity of the protected service, and thus data exchanged between the cli= ent and the protected service can be learned by the attacker. In the second= case, the client does not verify the identity of the multiplexed server (o= r fronting service), thus it is possible for an attacker to perform a Man-I= n-The-Middle attack between the client and the multiplexed server (or front= ing service). Thus it would be possible for the attacker to learn the ident= ity of the protected service. These designs require that the client has some reasonable trust in these fr= onting services. If the fronting service is acting maliciously, it may re-d= irect the client's TLS connection to another service other than the intende= d protected service. The service receiving the client's TLS connection may = not have any way of verifying that the client intended to reach that partic= ular service if it is not able to decrypt the client's SNI; thus the protec= ted service also has to have reasonable trust in the fronting service. If t= he fronting service is not strongly authenticated, it can be spoofed by an = adversary or be subject to MITM attack. The multiplexed server or the fronting services could be pressured by adver= saries. By design, they could be forced to deny access to the protected ser= vice, or to divulge which client accessed it. But if MITM is possible, the = adversaries would also be able to pressure them into intercepting or spoofi= ng the communications between client and protected service. These approaches therefore concentrate trust in the multiplexed servers and= fronting services, making them attractive targets for adversaries, or for = operators of these services to install monitoring, redirection and censorsh= ip mechanisms. It is desirable for the identity of these multiplexed serve= rs and fronting services to be strongly authenticated and verifiable by bot= h the client and the protected service. -- Mark This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk --_000_LOXP123MB14163C2F40F312AA252FDE46D3CD0LOXP123MB1416GBRP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Some comments on draft-ietf-tls-sni-encryption-03:

 

Section 2.3 “End-to-end alternatives”

“Enterprises can deploy monitoring software to= control usage of the enterprises [sic] computers.”
At the moment enterprises have the option of installing a firewall performi= ng SNI filtering to black-list connections to certain websites. With SNI en= cryption this becomes ineffective. This draft should describe the privacy i= mpact of enterprises adopting the proposed mitigation strategy of deploying monitoring software.  Simil= arly, the privacy impact of introducing “opt in” filtering of D= NS and packet marking to determine QoS should be addressed. The privacy gai= ns of encrypting SNI need to be weighed against the privacy losses of adopting these mitigations and at the moment this draft = does not do that.

 

 

Section 3.6 “Proper security context”

This section currently describes one class of soluti= ons where there is a single TLS handshake between the client and the multip= lexed server or fronting service, but there is another class, where the TLS= handshake is between the client and the protected service. The text in this section should be expanded to enco= mpass both classes (or it could be written as two separate sections if clea= rer). The text should also draw out that the client and the protected servi= ce are placing a great deal of trust in the fronting service, which becomes a very powerful part of the network= and hence a very attractive target for attackers or malicious operators.

 

As a suggestion, consider the following alternative = text for section 3.6:

 


We can design solutions in which the multiplexed server or a fronting servi= ce act as a relay to reach the protected service. Some of those solutions i= nvolve just one TLS handshake between the client and the multiplexed server= (or fronting service). Others involve just one TLS handshake between the client and the protected service.

In the first case, the master secret is verified by verifying a certificate= provided by the multiplexed server (or fronting service), but not by the p= rotected service. In the second case, the master secret is verified by veri= fying a certificate provided by the protected service.

In the first case, the client is exposed to a Man-In-The-Middle attack by t= he multiplexed server (or fronting service). The client does not verify the= identity of the protected service, and thus data exchanged between the cli= ent and the protected service can be learned by the attacker. In the second case, the client does not verify= the identity of the multiplexed server (or fronting service), thus it is p= ossible for an attacker to perform a Man-In-The-Middle attack between the c= lient and the multiplexed server (or fronting service). Thus it would be possible for the attacker to learn= the identity of the protected service.

These designs require that the client has some reasonable trust in these fr= onting services. If the fronting service is acting maliciously, it may re-d= irect the client's TLS connection to another service other than the intende= d protected service. The service receiving the client's TLS connection may not have any way of verifying th= at the client intended to reach that particular service if it is not able t= o decrypt the client's SNI; thus the protected service also has to have rea= sonable trust in the fronting service. If the fronting service is not strongly authenticated, it can be spoofed b= y an adversary or be subject to MITM attack.

The multiplexed server or the fronting services could be pressured by adver= saries. By design, they could be forced to deny access to the protected ser= vice, or to divulge which client accessed it. But if MITM is possible, the = adversaries would also be able to pressure them into intercepting or spoofing the communications between cli= ent and protected service.

These approaches therefore concentrate trust in the multiplexed servers and= fronting services, making them attractive targets for adversaries, or for = operators of these services to install monitoring, redirection and censorsh= ip mechanisms.  It is desirable for the identity of these multiplexed servers and fronting services to be = strongly authenticated and verifiable by both the client and the protected = service.


-- Mark

 

 

 

 

 

This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk --_000_LOXP123MB14163C2F40F312AA252FDE46D3CD0LOXP123MB1416GBRP_-- From nobody Wed Oct 31 12:22:31 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7DF129C6A for ; Wed, 31 Oct 2018 12:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZmq0nJbGU41 for ; Wed, 31 Oct 2018 12:22:27 -0700 (PDT) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8732F1277C8 for ; Wed, 31 Oct 2018 12:22:27 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id d19so312014qkg.5 for ; Wed, 31 Oct 2018 12:22:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=G31LEUYrgalbIacEppmxiEAcmpMKg97uCokDeK9SEJ8=; b=JrHlr07zqaZkMdol/PJlznR+pC3m9yHLlABCeNS0TtgClmpgZI7dNDUF5l7o7wEeoA TCrGTtR7tmY4BcAgFBVrp/q2PI3woshKLVC3tN2YMcaA3KeENju1EG66nOtqflIVNn5z t6CYmyD6HQKGONftCRtPz0K4BdiOZ7JN9vAAw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=G31LEUYrgalbIacEppmxiEAcmpMKg97uCokDeK9SEJ8=; b=NAC5bSNG+2UQjQPf6W1cIoveUx+sw/D8iymQM4KOgfptB1ixNd0QW8yrCKlm4gNSWy aQ5TEejh0qYq5Arq1r1/nbDFu0CC/BN8ySHS5Q2Fz4MoDn4zWQ1xI5FzCvQMk8/sVZYs QeE5/zV6BeCm+xfBlrRlMRrxt7XXxFfH/WE6dxC/smOPh3W3KAyuv7ERy/vmjzBtpAzJ VEIxdLKxzrowglniLZepKPaAgPMbM03AJZP6DA8sQu7eKzx5nasF0jY8W29EJvie05xi zbMwYLp+oYZDocaYmisaovLnyXPygwAxuqpZBC8v49AZ0MUOVMOvFbWVeluLYVlUm2pY u4Jg== X-Gm-Message-State: AGRZ1gJwmvZf7DI8pBXW6s/ZYd/OWTBNF/NJ+lr1JTnV5rDsfdiU2b1N 2fcoVQVAfriXG9c5MX/8eJNtdzUhHVY= X-Google-Smtp-Source: AJdET5dDd/8D6QKPEk7RD0qMcyxzk76J/etBFNPSKIrRTX6g1axUJRXcli8uCMefWGny0WrFWiEldQ== X-Received: by 2002:a37:8806:: with SMTP id k6-v6mr3786075qkd.119.1541013746539; Wed, 31 Oct 2018 12:22:26 -0700 (PDT) Received: from [172.16.0.18] ([96.231.224.191]) by smtp.gmail.com with ESMTPSA id y14sm5495625qkb.2.2018.10.31.12.22.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 Oct 2018 12:22:26 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: Date: Wed, 31 Oct 2018 15:22:24 -0400 To: tls@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [TLS] TLS@IETF103 agenda X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2018 19:22:30 -0000 All, The agenda has been posted: https://datatracker.ietf.org/meeting/103/materials/agenda-103-tls-00 Note that we have two sessions: --------------------------------------------- tls Session 1 Monday, 5 November 2018, 1350-1550 Room Name: Chitlada 2 --------------------------------------------- tls Session 2 Wednesday, 7 November 2018, 1120-1220 Room Name: Chitlada 1 --------------------------------------------- Links for remote participation (meetech, jabber, audio) can be found on = this page: https://datatracker.ietf.org/meeting/agenda/ spt= From nobody Wed Oct 31 12:23:52 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E161277C8 for ; Wed, 31 Oct 2018 12:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdtWtAzGQaXN for ; Wed, 31 Oct 2018 12:23:47 -0700 (PDT) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C741129C6A for ; Wed, 31 Oct 2018 12:23:47 -0700 (PDT) Received: by mail-qt1-x834.google.com with SMTP id v1-v6so14247199qtq.5 for ; Wed, 31 Oct 2018 12:23:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=46xq1Js1Mb5BQphfqUBH86BU1ibHWUVIFa1EfRUBGa4=; b=HVFvehMm8ZDStASv2BYpcCDGK7BKV8G20bIKzxHf2l0jOEHtNYrZLhlz0HcxeCTAtQ U4HdMx8KG51RMtiMEa8p61xPYswIXDEZTIZYBgPYmD0tIpQ+eY9X368BjV4CDnmc6tFp xLS7uesohey0GWQ36/zwbCpzMR3SCnMokro90= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=46xq1Js1Mb5BQphfqUBH86BU1ibHWUVIFa1EfRUBGa4=; b=BUHEzXB0f9+iN8WArQeR2KjYIyDNmFarb2NLagy5OJpvAp5yOEjjoS+U5rKIZl29xV otR0wVsrSscWJssWF27L3J3cCuRGDiZoMXWr/7iRTIOjMX2FDXLgwh83JLdJd/tc40Mh 9eU+3h4lFDmg2vzybeOxgmn0IAD7qsewlDbnGRTXW3TmHbeC4wgUBr569J+v+zM7zbN3 EgVgzhKoSQHFlInzO/ktJWFa6Xq1vYFVfcGIbnOtTlC4DqRh83YLmVCSholsio1LqTUj LwOtxpEQr+47It7P8FXjyBq5a215Qr3cI4IGCdfehxQfa1pa+Saiap+U3ExSwsqetxe5 YGNw== X-Gm-Message-State: AGRZ1gK9p4Rj9Ga09EUuijvpI8W5BVOqLO5YFLLoqPKawA5FyJGfacko fbo85XJc26I5A4OEs6yvVP95m2RWKCk= X-Google-Smtp-Source: AJdET5daLvn8U1pcR6vkB4PmUsC/XsHFFMn3t3CXWVat3dNtM0UeBpu93ELV0fbMRuaJhTyXtOYFRw== X-Received: by 2002:a0c:c3c8:: with SMTP id p8mr4024905qvi.90.1541013826238; Wed, 31 Oct 2018 12:23:46 -0700 (PDT) Received: from [172.16.0.18] ([96.231.224.191]) by smtp.gmail.com with ESMTPSA id z31-v6sm20900693qth.67.2018.10.31.12.23.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 Oct 2018 12:23:45 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: Date: Wed, 31 Oct 2018 15:23:44 -0400 To: tls@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [TLS] TLS@IETF103 slides X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2018 19:23:50 -0000 If you requested time on the agenda please send me your slides ASAP. = Our session is Monday afternoon so please send them to me no later than = Sunday evening (BKK time) so that WG participants will at least have = some time to review them. spt= From nobody Wed Oct 31 12:25:56 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C10129C6A for ; Wed, 31 Oct 2018 12:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9npzuFkDPQXM for ; Wed, 31 Oct 2018 12:25:54 -0700 (PDT) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D79211277C8 for ; Wed, 31 Oct 2018 12:25:53 -0700 (PDT) Received: by mail-qt1-x830.google.com with SMTP id q41-v6so18455068qtq.10 for ; Wed, 31 Oct 2018 12:25:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=YtYpnbKHlcsq+hBvVTC1J+S/VKm4Flm+qu2mlcrezPs=; b=ZdXYsmmptCO83RwVVAvFcFAq466oAW8RojGDgDKSBOrpAAKEkZllscCgEXxp8ExKP8 SBvxCttJDEO2ojECylg7s56/GvyqSWHvcZ26t7IajOiilpDIwHxZqCIVjydjkuDOrJQj FNilOFyiElgopd0k7VubWtj1CI1Czy3VhDeYM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=YtYpnbKHlcsq+hBvVTC1J+S/VKm4Flm+qu2mlcrezPs=; b=lFLB1+CzQNb7V28QqdAICgDgINB/77pq+v7FNIV0eU1Rlly3NZ8jqb31EGm/KzYvG8 u6R9kOt5hoaS0uX7Br6VrEFKtTUXCF7iWdqWMd1cSCW8nscS1jR7qaGYoUbE/BpizAe3 4aBaRuNcFMguOK21ppEeAqXpmtweisgfx8LlryczYY4d6J+rK/8K84i1OXsupt3wAwwx cRtZnkqap6qTcfEO2EhT+c6yPDuZjvZQtfm5fd07WuKPl5nRpZCtz7sae0e8oa+4syAP Cuf4VGZ2k/mYbF9sObNTmrZvpaF4jgvvSaFQ5XchDvmbYAenlNuRSGSwD6XqoOYYpWYe A62g== X-Gm-Message-State: AGRZ1gIiyhomDJ5Yw3PEHiBsuUVOnUyOKsH0p5V/myVdDW6uSpBztfic 3THpyrguLcqVPqFh1TaWR/kj1JfXfYM= X-Google-Smtp-Source: AJdET5fxQNXv3oTbaLeApA5X4cwqDhInl02fPD/jl//CFeP7LdZH75HTwpeeiTVFYIiPp86ZZeFVNw== X-Received: by 2002:a0c:e84f:: with SMTP id l15mr3916943qvo.124.1541013952885; Wed, 31 Oct 2018 12:25:52 -0700 (PDT) Received: from [172.16.0.18] ([96.231.224.191]) by smtp.gmail.com with ESMTPSA id m188-v6sm10738651qkb.24.2018.10.31.12.25.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 Oct 2018 12:25:52 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: Date: Wed, 31 Oct 2018 15:25:51 -0400 To: tls@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [TLS] TLS@IETF103 requests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2018 19:25:55 -0000 If you are interested in taking minutes or being the jabber scribe = please let the chair knows tls-chairs@ietf.org. Please note the minutes = do not need to a blow by blow account of the sessions. We are looking = for important points and decisions made. spt= From nobody Wed Oct 31 20:25:10 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 031761277CC for ; Wed, 31 Oct 2018 20:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H87VCGihYH5b for ; Wed, 31 Oct 2018 20:25:07 -0700 (PDT) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 203BA12426A for ; Wed, 31 Oct 2018 20:25:07 -0700 (PDT) Received: by mail-qk1-x731.google.com with SMTP id d135so10456225qkc.12 for ; Wed, 31 Oct 2018 20:25:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=sr47tflHOrY380J+oeMZ01Y4c8VARkOdlNET7qt8Cz0=; b=lEuXsl8FWk18lc5fS+EjjRO83UIMggQ5xwQOLM+CQrXvlOwTJ7OegM6536mwMW/kL0 Opvt/96dazASdTbz4A/PX8WlkIoDkR9P5yzeyWjitWx8PIFRXviOsIUT4yOHPkiwAPtV yVtZMpAFQWEJKN9F88WCmc2vzVblM8vcenQyI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=sr47tflHOrY380J+oeMZ01Y4c8VARkOdlNET7qt8Cz0=; b=dYknK8jqds+mYCHxnsHnDvOTwyUQ2LTiEys/wWMGxs+xAAA+loYduRWGJH2JnxfPgD LXv946Gpq4TZp31E94c9+5/PblqxovNCSY0sZekjrU/inPPDMBv9qD002LYztBnOBFY3 zqjz/vDEuCxw99fc/eF8Uueh12FmafVCEaG55dDeZtoSLjkwjXdTvpNByMSN2iLXEP+u u7/rvlop3Jt/sfMXN6jf3iH8DMZ7DyHFsuibq8x9TN3ILzXfNhAf80cmY7SHzDQz3GJw VJiKR1Mdz975pfXXcQiRYz7Svm6pXn9ibbR6cyInrxL9w88F8952gX914KuhLQEvGn4f SwEg== X-Gm-Message-State: AGRZ1gJ3/UGfrT6Vdc3OuOd4S/QnY/XGpbK0rawvOIsvxd4JVBloA0i3 LP6MBhRLK/3+svGykysiISjIF5E6LCc= X-Google-Smtp-Source: AJdET5d+Qf3f6qOXitbasY1IoyKsRW42QQXJTisiYVNcTzBlOWx/1NYo6IN5JQ5qv1MM2dO4j/LmsA== X-Received: by 2002:ae9:ef14:: with SMTP id d20mr4994441qkg.147.1541042706114; Wed, 31 Oct 2018 20:25:06 -0700 (PDT) Received: from [172.16.0.18] ([96.231.224.191]) by smtp.gmail.com with ESMTPSA id p3-v6sm15819315qtc.81.2018.10.31.20.25.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 Oct 2018 20:25:05 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 31 Oct 2018 23:25:03 -0400 References: To: tls@ietf.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [TLS] TLS@IETF103 slides X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2018 03:25:09 -0000 I have posted the chairs=E2=80=99 slides and associated drafts with the = appropriate sessions: https://datatracker.ietf.org/meeting/103/session/tls spt > On Oct 31, 2018, at 15:23, Sean Turner wrote: >=20 > If you requested time on the agenda please send me your slides ASAP. = Our session is Monday afternoon so please send them to me no later than = Sunday evening (BKK time) so that WG participants will at least have = some time to review them. >=20 > spt