From nobody Sun Jan 1 09:43:42 2017 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 1248F129448 for ; Sun, 1 Jan 2017 09:43:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 loJSYAlfQLuc for ; Sun, 1 Jan 2017 09:43:37 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::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 9F6C3129447 for ; Sun, 1 Jan 2017 09:43:37 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id t125so255877923ywc.1 for ; Sun, 01 Jan 2017 09:43:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=BTg9PuRdvsC9eHjhtavCueO9/3I7UxAJaqET52ZI7og=; b=DgGecpmtHqN6S14q4UFUYdKbrA9fKGA9VEiUsFnkRUY/h2DoseWiL2+FZPw3KV/rAr xl9fTnD1qxojODE9GslywuJPZu1gGZUrwDsf/RvAU+erelfbjbQCHocBA71VJalIYUZ0 d/2Z/lowWXaTHQNc692G69Uz0VWlMg8M+9kMgIQDwjN9G/bajxJT7890S+2gOke2DQEW X5cnIum3nlp8BEam6HANxIpBqny31F5Okaj7ATkHVeUlSi4PgSjbYa5Pqtd/0Z46lnRf CrjKit74rHTfJH6A3QWr8IvVYe6KZ8ph8g3IFHsaiOmxQ554ZUnduymN6ekAVZNNlmeV vf7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=BTg9PuRdvsC9eHjhtavCueO9/3I7UxAJaqET52ZI7og=; b=YUm77Nscp6bt9xqiWruyzkw7V/CNQbTnSEbs8A5o0HMKM9mnN3/XxPXu4AQ1vBeZk0 7liyy314/W8f1uWyBUb+pRXvzDjHBR+ARoSqRLlGbSRZZxawrU6nP5hikGzbrA+4DKlJ uggyT994Nlx3Z03n8whNcWfESNxDcbdcRGLlnWIqBd1uIeb+AogwDPgqZEJNG5GOchGW 63wTe0gQmuRkezLvP/+hp50pQsDL2Jrz2VFjbYu514xGK6PpM7rT5YiUyeQYWk/P2LbB N5T9yQYAm7bf0FMgfhwqjYpXubhoa5r13VgpHUi0s2pucJ+X4NNSr9b1RTvVTGOxJx6m pw/w== X-Gm-Message-State: AIkVDXIynPFje5nsKe0Em3WbcGZ9zik+lXJcd4RTgY+hRhHBHkAkG0mOeZCPdNPkfJEX0lakTRSzDnjyrvjwXQ== X-Received: by 10.129.102.132 with SMTP id a126mr50852879ywc.160.1483292616759; Sun, 01 Jan 2017 09:43:36 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.37.44.141 with HTTP; Sun, 1 Jan 2017 09:43:06 -0800 (PST) In-Reply-To: References: From: Hugo Krawczyk Date: Sun, 1 Jan 2017 12:43:06 -0500 X-Google-Sender-Auth: i1UqpnB8Xkz5QDYgL_dZkDkEQ84 Message-ID: To: Adam Langley Content-Type: multipart/alternative; boundary=001a114901b6851d3105450bf923 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)DHE public values be fresh X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 01 Jan 2017 17:43:41 -0000 --001a114901b6851d3105450bf923 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There is more than one way to "backdoor" the use of DH (i.e., to not enforce forward secrecy) and some of these ways are completely undetectable (in particular, they would not repeat DH values). One has to be careful not to give a false sense of security by the illusion that not detecting DH repetition guarantees forward secrecy (FS). The value of a MUST NOT that cannot be enforced is debatable even though it may serve as a strong message to implementers that FS is an important property to comply with (which is the domain of SHOULD). Another consideration is that there are applications where FS is of little value, e.g. anything where the requirement is authentication and not secrecy or where the secrecy requirement itself is ephemeral. Just to make it clear: I have been a supporter and promoter of forward secrecy since the early days of IPsec and I think it is the most important new feature of TLS 1.3, so the above should be understood as lukewarm feelings towards FS. Just that we have to understand that we cannot have an "anti-backdoor" guarantee and that there may be applications with legitimate reasons not to use FS. On Sat, Dec 31, 2016 at 1:36 PM, Adam Langley wrote: > (Note: I'm reordering Brian's paragraphs here so that I can address > all of those on a single topic at a time.) > > On Thu, Dec 29, 2016 at 4:29 PM, Brian Smith wrote= : > > It would make self-hosting a small that can survive a spike in traffic > > ("slashdot effect") more difficult, thus encouraging sites to use > > CDNs, which decrease the integrity, confidentiality, and privacy > > properties of all connections between the client and the origin > > server. Unfortunately I don't know how to quantify that. > > > > Another unintended consequence is that it makes the PSK modes > > relatively more attractive. For some very small devices doing ECDH > > agreement on every connection and only doing a occasionally doing a > > ECDH keygen could be at the edge of their performance/power limits, > > and needing to do the ECDH keygen for every connection could easily > > make using ECDH prohibitive. OTOH, we don't want these devices to use > > have a fixed ECDH key burned into their ROM, or similar, either. > > > > Another unintended consequence is that it makes resumption (formulated > > as a sort of server-generated PSK in TLS 1.3) more necessary. Although > > many implementations will probably implement resumption, I think there > > are a lot of cases where one might prefer to avoid implementing and/or > > enabling it. Also, even when it is enabled, making ECDH more expensive > > relative to PSK/resumption would encourage building more complex > > server software to distribute PSKs across machines. And/or the server > > may choose to reuse PSKs longer. And/or the server may choose to use > > the non-ECDHE form of PSK-based resumption (IIUC). Again, though, I > > can't quantify the effect here. > > > > With all this in mind, absent other information. In the case of > > servers hosting websites, I do think a limit of less than a minute is > > reasonable. However, I think for the small device (IoT) case, the > > limit should be longer, perhaps even hours. > > In practice, at the moment, sites are generally using RSA > certificates, so a small device getting slashdotted would be dominated > by the RSA signing costs rather than the ECDHE. > > But let's posit EdDSA certificates, where ECDHE generation might then > account for a 1/3 of the handshake cost. You make a good point that we > don't want to push low-end devices into PSK. Also, small devices are > less likely to be able to afford the tables that make fixed-base > operations fast. > > I don't actually object to allowing servers to cache a ECDHE public > value for a small about of time. (QUIC currently does so for 30 > seconds.) But I was worried about the arguments over the duration if I > specified one :) > > Consider the motivations here: > > 1) We know that some implementations have gotten this wrong with TLS > 1.2 and cached values for far too long. Presumably if they were to be > naively extended to TLS 1.3 this issue would carry over. > > 2) We probably disagree with this banking industry desire to be able > to backdoor their TLS connections, but we're not the police and fixing > DH values is probably how they would do it. If it's going to be A > Thing then it's much more likely that things will get misconfigured > and it'll be enabled in places where it shouldn't be. If we have no > detection mechanism then what we'll probably end up with is a Blackhat > talk in a few years time about how x% of banks botched forward > security at their frontends. > > Say that a value of an hour makes sense for some device and we feel > that an hour's forward-security window is reasonable for security. The > issue is that it significantly diminishes our detection ability > because clients need to remember more than an hour's worth of values > and I don't know if we can dedicate that amount of storage to this. > > Since I think the utility of this falls off as a reciprocal, I'll try > making a concrete suggestion for a time limit: 10 seconds. > > >> Also, this cost doesn't seem too high: 85.6% of servers /don't/ reuse > >> values and manage fine today. The generation of (EC)DH public values > >> is also a fixed-based operation and thus can be much faster than DH > >> key-agreement. > > > > According to the paper, a large majority of servers in the Alexa top > > 1M are reusing keys. That 14.4% number is a fraction of the 80% > > servers consistently in the Alexa top 1M that use browser-trusted > > certificates and that use ECDHE. IIUC, approximately 20% of servers in > > the Alexa top 1M that use browser-trusted certificates are using RSA > > key exchange, which means they are also reusing the same key for every > > connection. Also, according to the paper, more than half of servers > > aren't using TLS or aren't using browser-trusted certificates, which > > means that web browser connections to them are likely using the same > > NULL key. > > Thanks for pointing that out. I thought that saying "14.4%" and so on > was reasonable because it's a prevalence and we can assume that if > other sites did enable (EC)DHE then they would probably make the same > mistakes at a similar rate. But then I subtracted it from 100 and that > really doesn't make sense. > > > Also, the Alexa top 1M isn't representative of every use of TLS, but > > rather only one kind of application. > > > >> Lastly, some have proposed[2] (EC)DH reuse as a mechanism for enabling > >> TLS connections to be decrypted and monitored by a middlebox. TLS is > >> not designed to be decrypted by third-parties=E2=80=94that's kind of t= he > >> point. Thus anyone doing this should not be surprised to hit a few > >> MUST NOTs and, potentially, to have to configure implementations to > >> allow such a deployment. > > > > The (presumably) accidental reuse of keys for long periods of time is > > bad, and this MitM idea is even worse. But, if reuse were made a MUST > > NOT, wouldn't such systems just use a different, perhaps worse, more > > complex, and undetectable mechanism, like the one Dan Brown suggested > > in the earlier thread? I think we should assume that while we may be > > able to help prevent the former accidental badness with such a rule, > > such a mechanism probably isn't going to have much effect on the > > latter intentional badness. > > I much prefer people who are going to backdoor their TLS to use DH as > the mechanism rather than something less detectable. I don't expect a > MUST NOT will slow them down at all. I just want to ensure that this > doesn't accidently carry into 1.3, and that any unofficial backdoor > mechanism needed by some organisations doesn't inadvertently get > enabled more widely than planned. > > > Cheers > > AGL > > -- > Adam Langley agl@imperialviolet.org https://www.imperialviolet.org > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114901b6851d3105450bf923 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There is more than one way to "backdoor&qu= ot; the use of DH (i.e., to not enforce forward secrecy) and some of these = ways are completely undetectable (in particular, they would not repeat DH v= alues). One has to be careful not to give a false sense of security by the = illusion that not detecting DH repetition guarantees forward secrecy (FS). = The value of a MUST NOT that cannot be enforced is debatable even though it= may serve as a strong message to implementers that FS is an important prop= erty to comply with (which is the domain of SHOULD). Another consideration = is that there are applications where FS is of little value, e.g. anything w= here the requirement is authentication and not secrecy or where the secrecy= requirement itself is ephemeral.

Just to make it c= lear: I have been a supporter and promoter of forward secrecy since the ear= ly days of IPsec and I think it is the most important new feature of TLS 1.= 3, so the above should be understood as lukewarm feelings towards FS. Just = that we have to understand that we cannot have an "anti-backdoor"= guarantee and that there may be applications with legitimate reasons not t= o use FS.

On Sat, Dec 31, 2016 at 1:36 PM, Adam Langley &l= t;agl@imperialv= iolet.org> wrote:
(Note: I= 'm reordering Brian's paragraphs here so that I can address
all of those on a single topic at a time.)

On Thu, Dec 29, 2016 at 4:29 PM, Brian Smith <brian@briansmith.org> wrote:
> It would make self-hosting a small that can survive a spike in traffic=
> ("slashdot effect") more difficult, thus encouraging sites t= o use
> CDNs, which decrease the integrity, confidentiality, and privacy
> properties of all connections between the client and the origin
> server. Unfortunately I don't know how to quantify that.
>
> Another unintended consequence is that it makes the PSK modes
> relatively more attractive. For some very small devices doing ECDH
> agreement on every connection and only doing a occasionally doing a > ECDH keygen could be at the edge of their performance/power limits, > and needing to do the ECDH keygen for every connection could easily > make using ECDH prohibitive. OTOH, we don't want these devices to = use
> have a fixed ECDH key burned into their ROM, or similar, either.
>
> Another unintended consequence is that it makes resumption (formulated=
> as a sort of server-generated PSK in TLS 1.3) more necessary. Although=
> many implementations will probably implement resumption, I think there=
> are a lot of cases where one might prefer to avoid implementing and/or=
> enabling it. Also, even when it is enabled, making ECDH more expensive=
> relative to PSK/resumption would encourage building more complex
> server software to distribute PSKs across machines. And/or the server<= br> > may choose to reuse PSKs longer. And/or the server may choose to use > the non-ECDHE form of PSK-based resumption (IIUC). Again, though, I > can't quantify the effect here.
>
> With all this in mind, absent other informatio= n. In the case of
> servers hosting websites, I do think a limit of less than a minute is<= br> > reasonable. However, I think for the small device (IoT) case, the
> limit should be longer, perhaps even hours.

In practice, at the moment, sites are generally using RSA
certificates, so a small device getting slashdotted would be dominated
by the RSA signing costs rather than the ECDHE.

But let's posit EdDSA certificates, where ECDHE generation might then account for a 1/3 of the handshake cost. You make a good point that we
don't want to push low-end devices into PSK. Also, small devices are less likely to be able to afford the tables that make fixed-base
operations fast.

I don't actually object to allowing servers to cache a ECDHE public
value for a small about of time. (QUIC currently does so for 30
seconds.) But I was worried about the arguments over the duration if I
specified one :)

Consider the motivations here:

1) We know that some implementations have gotten this wrong with TLS
1.2 and cached values for far too long. Presumably if they were to be
naively extended to TLS 1.3 this issue would carry over.

2) We probably disagree with this banking industry desire to be able
to backdoor their TLS connections, but we're not the police and fixing<= br> DH values is probably how they would do it. If it's going to be A
Thing then it's much more likely that things will get misconfigured
and it'll be enabled in places where it shouldn't be. If we have no=
detection mechanism then what we'll probably end up with is a Blackhat<= br> talk in a few years time about how x% of banks botched forward
security at their frontends.

Say that a value of an hour makes sense for some device and we feel
that an hour's forward-security window is reasonable for security. The<= br> issue is that it significantly diminishes our detection ability
because clients need to remember more than an hour's worth of values and I don't know if we can dedicate that amount of storage to this.

Since I think the utility of this falls off as a reciprocal, I'll try making a concrete suggestion for a time limit: 10 seconds.

>> Also, this cost doesn't seem too high: 85.6% of servers /don&#= 39;t/ reuse
>> values and manage fine today. The generation of (EC)DH public valu= es
>> is also a fixed-based operation and thus can be much faster than D= H
>> key-agreement.
>
> According to the paper, a large majority of servers in the Alexa top > 1M are reusing keys. That 14.4% number is a fraction of the 80%
> servers consistently in the Alexa top 1M that use browser-trusted
> certificates and that use ECDHE. IIUC, approximately 20% of servers in=
> the Alexa top 1M that use browser-trusted certificates are using RSA > key exchange, which means they are also reusing the same key for every=
> connection. Also, according to the paper, more than half of servers > aren't using TLS or aren't using browser-trusted certificates,= which
> means that web browser connections to them are likely using the same > NULL key.

Thanks for pointing that out. I thought that saying "14.4%"= ; and so on
was reasonable because it's a prevalence and we can assume that if
other sites did enable (EC)DHE then they would probably make the same
mistakes at a similar rate. But then I subtracted it from 100 and that
really doesn't make sense.

> Also, the Alexa top 1M isn't representative of every use of TLS, b= ut
> rather only one kind of application.
>
>> Lastly, some have proposed[2] (EC)DH reuse as a mechanism for enab= ling
>> TLS connections to be decrypted and monitored by a middlebox. TLS = is
>> not designed to be decrypted by third-parties=E2=80=94that's k= ind of the
>> point. Thus anyone doing this should not be surprised to hit a few=
>> MUST NOTs and, potentially, to have to configure implementations t= o
>> allow such a deployment.
>
> The (presumably) accidental reuse of keys for long periods of time is<= br> > bad, and this MitM idea is even worse. But, if reuse were made a MUST<= br> > NOT, wouldn't such systems just use a different, perhaps worse, mo= re
> complex, and undetectable mechanism, like the one Dan Brown suggested<= br> > in the earlier thread? I think we should assume that while we may be > able to help prevent the former accidental badness with such a rule, > such a mechanism probably isn't going to have much effect on the > latter intentional badness.

I much prefer people who are going to backdoor their TLS to use DH a= s
the mechanism rather than something less detectable. I don't expect a MUST NOT will slow them down at all. I just want to ensure that this
doesn't accidently carry into 1.3, and that any unofficial backdoor
mechanism needed by some organisations doesn't inadvertently get
enabled more widely than planned.


Cheers

AGL

--
Adam Langley agl@imperialviolet.o= rg https://www.imperialviolet.org

____________________________= ___________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a114901b6851d3105450bf923-- From nobody Sun Jan 1 11:25:36 2017 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 6A3DD1293F3 for ; Sun, 1 Jan 2017 11:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.7 X-Spam-Level: X-Spam-Status: No, score=-5.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.1, 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 G62ArHvXIyV5 for ; Sun, 1 Jan 2017 11:25:33 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFD26126B6D for ; Sun, 1 Jan 2017 11:25:32 -0800 (PST) Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs215cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Jan 2017 14:25:31 -0500 Received: from XCT116CNC.rim.net (10.65.161.216) by XCT106CNC.rim.net (10.65.161.206) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 1 Jan 2017 14:25:30 -0500 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT116CNC.rim.net ([::1]) with mapi id 14.03.0319.002; Sun, 1 Jan 2017 14:25:29 -0500 From: Dan Brown To: Hugo Krawczyk , Adam Langley Thread-Topic: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)DHE public values be fresh Thread-Index: AQHSZFacWjk79u0NfEqEhUFEOLMDMKEkAPK3 Date: Sun, 1 Jan 2017 19:25:29 +0000 Message-ID: <20170101192527.5705805.69243.8791@blackberry.com> References: , In-Reply-To: Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_201701011925275705805692438791blackberrycom_" MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)DHE public values be fresh X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 01 Jan 2017 19:25:35 -0000 --_000_201701011925275705805692438791blackberrycom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable There is more than 1 reason not to re-use ephemerals: forward secrecy (rece= nt discussion), better resistance to side channels and fault attacks (e.g.,= invalid curves), and (informally?) less theoretical reliance of the strong= /static Diffie-Hellman problems. Re-use should be disallowed, though I agree run-time detection of a peer's = re-use does not solve much. Sent from my BlackBerry 10 smartphone on the Rogers network. From: Hugo Krawczyk Sent: Sunday, January 1, 2017 12:43 PM To: Adam Langley Cc: tls@ietf.org Subject: Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)DHE public values= be fresh There is more than one way to "backdoor" the use of DH (i.e., to not enforc= e forward secrecy) and some of these ways are completely undetectable (in p= articular, they would not repeat DH values). One has to be careful not to g= ive a false sense of security by the illusion that not detecting DH repetit= ion guarantees forward secrecy (FS). The value of a MUST NOT that cannot be= enforced is debatable even though it may serve as a strong message to impl= ementers that FS is an important property to comply with (which is the doma= in of SHOULD). Another consideration is that there are applications where F= S is of little value, e.g. anything where the requirement is authentication= and not secrecy or where the secrecy requirement itself is ephemeral. Just to make it clear: I have been a supporter and promoter of forward secr= ecy since the early days of IPsec and I think it is the most important new = feature of TLS 1.3, so the above should be understood as lukewarm feelings = towards FS. Just that we have to understand that we cannot have an "anti-ba= ckdoor" guarantee and that there may be applications with legitimate reason= s not to use FS. On Sat, Dec 31, 2016 at 1:36 PM, Adam Langley > wrote: (Note: I'm reordering Brian's paragraphs here so that I can address all of those on a single topic at a time.) On Thu, Dec 29, 2016 at 4:29 PM, Brian Smith > wrote: > It would make self-hosting a small that can survive a spike in traffic > ("slashdot effect") more difficult, thus encouraging sites to use > CDNs, which decrease the integrity, confidentiality, and privacy > properties of all connections between the client and the origin > server. Unfortunately I don't know how to quantify that. > > Another unintended consequence is that it makes the PSK modes > relatively more attractive. For some very small devices doing ECDH > agreement on every connection and only doing a occasionally doing a > ECDH keygen could be at the edge of their performance/power limits, > and needing to do the ECDH keygen for every connection could easily > make using ECDH prohibitive. OTOH, we don't want these devices to use > have a fixed ECDH key burned into their ROM, or similar, either. > > Another unintended consequence is that it makes resumption (formulated > as a sort of server-generated PSK in TLS 1.3) more necessary. Although > many implementations will probably implement resumption, I think there > are a lot of cases where one might prefer to avoid implementing and/or > enabling it. Also, even when it is enabled, making ECDH more expensive > relative to PSK/resumption would encourage building more complex > server software to distribute PSKs across machines. And/or the server > may choose to reuse PSKs longer. And/or the server may choose to use > the non-ECDHE form of PSK-based resumption (IIUC). Again, though, I > can't quantify the effect here. > > With all this in mind, absent other information. In the case of > servers hosting websites, I do think a limit of less than a minute is > reasonable. However, I think for the small device (IoT) case, the > limit should be longer, perhaps even hours. In practice, at the moment, sites are generally using RSA certificates, so a small device getting slashdotted would be dominated by the RSA signing costs rather than the ECDHE. But let's posit EdDSA certificates, where ECDHE generation might then account for a 1/3 of the handshake cost. You make a good point that we don't want to push low-end devices into PSK. Also, small devices are less likely to be able to afford the tables that make fixed-base operations fast. I don't actually object to allowing servers to cache a ECDHE public value for a small about of time. (QUIC currently does so for 30 seconds.) But I was worried about the arguments over the duration if I specified one :) Consider the motivations here: 1) We know that some implementations have gotten this wrong with TLS 1.2 and cached values for far too long. Presumably if they were to be naively extended to TLS 1.3 this issue would carry over. 2) We probably disagree with this banking industry desire to be able to backdoor their TLS connections, but we're not the police and fixing DH values is probably how they would do it. If it's going to be A Thing then it's much more likely that things will get misconfigured and it'll be enabled in places where it shouldn't be. If we have no detection mechanism then what we'll probably end up with is a Blackhat talk in a few years time about how x% of banks botched forward security at their frontends. Say that a value of an hour makes sense for some device and we feel that an hour's forward-security window is reasonable for security. The issue is that it significantly diminishes our detection ability because clients need to remember more than an hour's worth of values and I don't know if we can dedicate that amount of storage to this. Since I think the utility of this falls off as a reciprocal, I'll try making a concrete suggestion for a time limit: 10 seconds. >> Also, this cost doesn't seem too high: 85.6% of servers /don't/ reuse >> values and manage fine today. The generation of (EC)DH public values >> is also a fixed-based operation and thus can be much faster than DH >> key-agreement. > > According to the paper, a large majority of servers in the Alexa top > 1M are reusing keys. That 14.4% number is a fraction of the 80% > servers consistently in the Alexa top 1M that use browser-trusted > certificates and that use ECDHE. IIUC, approximately 20% of servers in > the Alexa top 1M that use browser-trusted certificates are using RSA > key exchange, which means they are also reusing the same key for every > connection. Also, according to the paper, more than half of servers > aren't using TLS or aren't using browser-trusted certificates, which > means that web browser connections to them are likely using the same > NULL key. Thanks for pointing that out. I thought that saying "14.4%" and so on was reasonable because it's a prevalence and we can assume that if other sites did enable (EC)DHE then they would probably make the same mistakes at a similar rate. But then I subtracted it from 100 and that really doesn't make sense. > Also, the Alexa top 1M isn't representative of every use of TLS, but > rather only one kind of application. > >> Lastly, some have proposed[2] (EC)DH reuse as a mechanism for enabling >> TLS connections to be decrypted and monitored by a middlebox. TLS is >> not designed to be decrypted by third-parties=97that's kind of the >> point. Thus anyone doing this should not be surprised to hit a few >> MUST NOTs and, potentially, to have to configure implementations to >> allow such a deployment. > > The (presumably) accidental reuse of keys for long periods of time is > bad, and this MitM idea is even worse. But, if reuse were made a MUST > NOT, wouldn't such systems just use a different, perhaps worse, more > complex, and undetectable mechanism, like the one Dan Brown suggested > in the earlier thread? I think we should assume that while we may be > able to help prevent the former accidental badness with such a rule, > such a mechanism probably isn't going to have much effect on the > latter intentional badness. I much prefer people who are going to backdoor their TLS to use DH as the mechanism rather than something less detectable. I don't expect a MUST NOT will slow them down at all. I just want to ensure that this doesn't accidently carry into 1.3, and that any unofficial backdoor mechanism needed by some organisations doesn't inadvertently get enabled more widely than planned. Cheers AGL -- Adam Langley agl@imperialviolet.org https://= www.imperialviolet.org _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_201701011925275705805692438791blackberrycom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Sent from my BlackBerry 10 smartphone on = ;the Rogers network.
From: Hugo Krawczyk
Sent: Sunday, January 1, 2017 12:43 PM
To: Adam Langley
Cc: tls@ietf.org
Subject: Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)DHE p= ublic values be fresh

There is more than one way to "backdoor" the use of DH (i.e., to = not enforce forward secrecy) and some of these ways are completely undetect= able (in particular, they would not repeat DH values). One has to be carefu= l not to give a false sense of security by the illusion that not detecting DH repetition guarantees forward secrecy (= FS). The value of a MUST NOT that cannot be enforced is debatable even thou= gh it may serve as a strong message to implementers that FS is an important= property to comply with (which is the domain of SHOULD). Another consideration is that there are applicat= ions where FS is of little value, e.g. anything where the requirement is au= thentication and not secrecy or where the secrecy requirement itself is eph= emeral.

Just to make it clear: I have been a supporter and promoter of forward secr= ecy since the early days of IPsec and I think it is the most important new = feature of TLS 1.3, so the above should be understood as lukewarm feelings = towards FS. Just that we have to understand that we cannot have an "anti-backdoor" guarantee and = that there may be applications with legitimate reasons not to use FS.

On Sat, Dec 31, 2016 at 1:36 PM, Adam Langley <agl@imperia= lviolet.org> wrote:
(Note: I'm reordering Brian's paragraphs here so that I can address
all of those on a single topic at a time.)

On Thu, Dec 29, 2016 at 4:29 PM, Brian Smith <brian@briansmith.org> wrote:
> It would make self-hosting a small that can survive a spike in traffic=
> ("slashdot effect") more difficult, thus encouraging sites t= o use
> CDNs, which decrease the integrity, confidentiality, and privacy
> properties of all connections between the client and the origin
> server. Unfortunately I don't know how to quantify that.
>
> Another unintended consequence is that it makes the PSK modes
> relatively more attractive. For some very small devices doing ECDH
> agreement on every connection and only doing a occasionally doing a > ECDH keygen could be at the edge of their performance/power limits, > and needing to do the ECDH keygen for every connection could easily > make using ECDH prohibitive. OTOH, we don't want these devices to use<= br> > have a fixed ECDH key burned into their ROM, or similar, either.
>
> Another unintended consequence is that it makes resumption (formulated=
> as a sort of server-generated PSK in TLS 1.3) more necessary. Although=
> many implementations will probably implement resumption, I think there=
> are a lot of cases where one might prefer to avoid implementing and/or=
> enabling it. Also, even when it is enabled, making ECDH more expensive=
> relative to PSK/resumption would encourage building more complex
> server software to distribute PSKs across machines. And/or the server<= br> > may choose to reuse PSKs longer. And/or the server may choose to use > the non-ECDHE form of PSK-based resumption (IIUC). Again, though, I > can't quantify the effect here.
>
> With all this in mind, absent other informatio= n. In the case of
> servers hosting websites, I do think a limit of less than a minute is<= br> > reasonable. However, I think for the small device (IoT) case, the
> limit should be longer, perhaps even hours.

In practice, at the moment, sites are generally using RSA
certificates, so a small device getting slashdotted would be dominated
by the RSA signing costs rather than the ECDHE.

But let's posit EdDSA certificates, where ECDHE generation might then
account for a 1/3 of the handshake cost. You make a good point that we
don't want to push low-end devices into PSK. Also, small devices are
less likely to be able to afford the tables that make fixed-base
operations fast.

I don't actually object to allowing servers to cache a ECDHE public
value for a small about of time. (QUIC currently does so for 30
seconds.) But I was worried about the arguments over the duration if I
specified one :)

Consider the motivations here:

1) We know that some implementations have gotten this wrong with TLS
1.2 and cached values for far too long. Presumably if they were to be
naively extended to TLS 1.3 this issue would carry over.

2) We probably disagree with this banking industry desire to be able
to backdoor their TLS connections, but we're not the police and fixing
DH values is probably how they would do it. If it's going to be A
Thing then it's much more likely that things will get misconfigured
and it'll be enabled in places where it shouldn't be. If we have no
detection mechanism then what we'll probably end up with is a Blackhat
talk in a few years time about how x% of banks botched forward
security at their frontends.

Say that a value of an hour makes sense for some device and we feel
that an hour's forward-security window is reasonable for security. The
issue is that it significantly diminishes our detection ability
because clients need to remember more than an hour's worth of values
and I don't know if we can dedicate that amount of storage to this.

Since I think the utility of this falls off as a reciprocal, I'll try
making a concrete suggestion for a time limit: 10 seconds.

>> Also, this cost doesn't seem too high: 85.6% of servers /don't/ re= use
>> values and manage fine today. The generation of (EC)DH public valu= es
>> is also a fixed-based operation and thus can be much faster than D= H
>> key-agreement.
>
> According to the paper, a large majority of servers in the Alexa top > 1M are reusing keys. That 14.4% number is a fraction of the 80%
> servers consistently in the Alexa top 1M that use browser-trusted
> certificates and that use ECDHE. IIUC, approximately 20% of servers in=
> the Alexa top 1M that use browser-trusted certificates are using RSA > key exchange, which means they are also reusing the same key for every=
> connection. Also, according to the paper, more than half of servers > aren't using TLS or aren't using browser-trusted certificates, which > means that web browser connections to them are likely using the same > NULL key.

Thanks for pointing that out. I thought that saying "14.4%"= ; and so on
was reasonable because it's a prevalence and we can assume that if
other sites did enable (EC)DHE then they would probably make the same
mistakes at a similar rate. But then I subtracted it from 100 and that
really doesn't make sense.

> Also, the Alexa top 1M isn't representative of every use of TLS, but > rather only one kind of application.
>
>> Lastly, some have proposed[2] (EC)DH reuse as a mechanism for enab= ling
>> TLS connections to be decrypted and monitored by a middlebox. TLS = is
>> not designed to be decrypted by third-parties=97that's kind of the=
>> point. Thus anyone doing this should not be surprised to hit a few=
>> MUST NOTs and, potentially, to have to configure implementations t= o
>> allow such a deployment.
>
> The (presumably) accidental reuse of keys for long periods of time is<= br> > bad, and this MitM idea is even worse. But, if reuse were made a MUST<= br> > NOT, wouldn't such systems just use a different, perhaps worse, more > complex, and undetectable mechanism, like the one Dan Brown suggested<= br> > in the earlier thread? I think we should assume that while we may be > able to help prevent the former accidental badness with such a rule, > such a mechanism probably isn't going to have much effect on the
> latter intentional badness.

I much prefer people who are going to backdoor their TLS to use DH a= s
the mechanism rather than something less detectable. I don't expect a
MUST NOT will slow them down at all. I just want to ensure that this
doesn't accidently carry into 1.3, and that any unofficial backdoor
mechanism needed by some organisations doesn't inadvertently get
enabled more widely than planned.


Cheers

AGL

--
Adam Langley agl@imperialviolet.o= rg https://www.imperialviolet.org
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--_000_201701011925275705805692438791blackberrycom_-- From nobody Sun Jan 1 14:39:03 2017 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 B3C161270B4 for ; Sun, 1 Jan 2017 14:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.1] 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 VBq4PfE-Ez3O for ; Sun, 1 Jan 2017 14:38:59 -0800 (PST) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id A41AC128BA2 for ; Sun, 1 Jan 2017 14:38:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id AA58F1879E; Mon, 2 Jan 2017 00:38:57 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id 5WMYqkgpT7uE; Mon, 2 Jan 2017 00:38:57 +0200 (EET) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 98BBDC4; Mon, 2 Jan 2017 00:29:38 +0200 (EET) Date: Mon, 2 Jan 2017 00:29:28 +0200 From: Ilari Liusvaara To: Hugo Krawczyk Message-ID: <20170101222928.GA18736@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)DHE public values be fresh X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 01 Jan 2017 22:39:02 -0000 On Sun, Jan 01, 2017 at 12:43:06PM -0500, Hugo Krawczyk wrote: > There is more than one way to "backdoor" the use of DH (i.e., to not > enforce forward secrecy) and some of these ways are completely undetectable > (in particular, they would not repeat DH values). One has to be careful not > to give a false sense of security by the illusion that not detecting DH > repetition guarantees forward secrecy (FS). The value of a MUST NOT that > cannot be enforced is debatable even though it may serve as a strong > message to implementers that FS is an important property to comply with > (which is the domain of SHOULD). Another consideration is that there are > applications where FS is of little value, e.g. anything where the > requirement is authentication and not secrecy or where the secrecy > requirement itself is ephemeral. My understanding of this matter is that this proposal isn't so much about forcing FS, but ensuring that servers don't _accidentially_ screw up FS, as many TLS 1.2 servers do, even when using ECDHE cipher- suites. Those servers cache ECDH keys and apparently have no facily to roll over ECDH keys as those use the same ones weeks or months over. If such ECDH key gets compromised on still-live server, you don't just get attacks where past connections have confidentiality compromised, but also attacks where _future_ connections have confidentialty and _integerity_ compromised. Yes, you can undetectalby undermine FS (and concrete methods of doing that have been proposed in discussions within this WG), but implementing that is nontrivial work, compared to just generating ECDH key on startup and reusing it for lifetime of the process. Also, when considering confidentiality, there is not just cofidentiality of information itself, but also confidentiality of access of information. I have seen lots of arguments against encryption that completely ignore that. -Ilari From nobody Sun Jan 1 20:09:11 2017 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 E78B012954B for ; Sun, 1 Jan 2017 20:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1] 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 wKxvNym9ipgG for ; Sun, 1 Jan 2017 20:09:07 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E7E112947F for ; Sun, 1 Jan 2017 20:09:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1483330146; x=1514866146; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wponG/hBdpxHnjsIYcOO35ziyy0k064+XMq6ID8xTp4=; b=H7eF/Nlg4GC4AkSlaItCIR5jByrRrycMqYEWyW7hqDNQUmQJffwTwKUA 5rDMAyMzN2sCG3p0xnwzr/JXQWp9gBwlevPZeNY1mhRrB22Yy4h7Z5F9U kEJmNJGIDaGi6n52hMKJg/RarjdR+JKrppUaYEl6p5qHANqvZxoz5ofYP 952gid7BXZr6jxuw3BbbSkyi72i+TbfovSBumYLM/ELEWZT3QQvPqT30r bJHTrVw1A8oQCNa8bK/9kT7rfXgtLLzGna/ywsVFadSe11RKRMX3OXoQ9 SC1z42a+XEvei7YCeo8qWm5DrEDdpA7uIcMr2QC7nGsSSxhle/ZoBU8Iu A==; X-IronPort-AV: E=Sophos;i="5.33,432,1477911600"; d="scan'208";a="123482679" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.3 - Outgoing - Outgoing Received: from uxcn13-ogg-b.uoa.auckland.ac.nz ([10.6.2.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 02 Jan 2017 17:09:03 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-b.UoA.auckland.ac.nz (10.6.2.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 2 Jan 2017 17:09:03 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Mon, 2 Jan 2017 17:09:03 +1300 From: Peter Gutmann To: Hugo Krawczyk , Adam Langley Thread-Topic: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)DHE public values be fresh Thread-Index: AQHSZFairLbDH8qWXUS+vlGTA4gOHKEkkwFS Date: Mon, 2 Jan 2017 04:09:02 +0000 Message-ID: <1483330131409.25713@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: Cc: "tls@ietf.org" Subject: Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)DHE public values be fresh X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 02 Jan 2017 04:09:09 -0000 Hugo Krawczyk writes:=0A= =0A= >there may be applications with legitimate reasons not to use FS. =0A= =0A= It's not so much reasons not to use FS (well, there are some specialised ca= ses=0A= where people want to do that as well), it's reasons to reuse (EC)DH values.= =0A= This isn't something that was ever mentioned in the spec, it's what develop= ers=0A= have implemented themselves in order to deal with high-load conditions.=A0 = This=0A= also means that no matter what the spec might say in the future, if you've = got=0A= a developer facing a situation where they need 480% of available CPU to=0A= service requests then they're going to do things like cache (EC)DH, regardl= ess=0A= of what the spec says.=A0 So making it a MUST NOT will end up as what someo= ne on=0A= PKIX once described as "workgroup posturing".=A0 Better to include an advis= ory=0A= note on using it, for example what TLS-LTS says:=0A= =0A= =A0=A0 TLS-LTS mandates the use of cipher suites that provide so-called=0A= =A0=A0 Perfect Forward Secrecy (PFS), in which an attacker can't record=0A= =A0=A0 sessions and decrypt them at a later date.=A0 The PFS property is=0A= =A0=A0 however impacted by the TLS session cache and session tickets, which= =0A= =A0=A0 allow an attacker to decrypt old sessions.=A0 The session cache is= =0A= =A0=A0 relatively short-term and only allows decryption while a session is= =0A= =A0=A0 held in the cache, but the use of long-term keys in combination with= =0A= =A0=A0 session tickets means that an attacker can decrypt any session used= =0A= =A0=A0 with that key, defeating PFS:=0A= =0A= =A0=A0 o=A0 Implementations SHOULD consider the impact of using session cac= hes=0A= =A0=A0=A0=A0=A0 and session tickets on PFS.=A0 Security issues in this area= can be=0A= =A0=A0=A0=A0=A0 mitigated by using short session cache expiry times, and av= oiding=0A= =A0=A0=A0=A0=A0 session tickets or changing the key used to encrypt them=0A= =A0=A0=A0=A0=A0 periodically.=0A= =0A= =A0=A0 Another form of cacheing that can affect security is the reuse of th= e=0A= =A0=A0 supposedly-ephemeral DH value y =3D g^x mod p or its elliptic curve= =0A= =A0=A0 equivalent. Instead of computing a fresh value for each session, som= e=0A= =A0=A0 servers for performance reasons compute the y value once and then re= use it=0A= =A0=A0 across multiple TLS sessions.=A0 If this is done then an attacker ca= n compute=0A= =A0=A0 the discrete log value from one TLS session and reuse it to attack l= ater=0A= =A0=A0 sessions:=0A= =0A= =A0=A0 o=A0 Implementations SHOULD consider the impact of reusing the y =3D= g^x=0A= =A0=A0=A0=A0=A0 mod p value across multiple TLS sessions, and avoid this re= use if=0A= =A0=A0=A0=A0=A0 possible.=A0 Where the reuse of y is unavoidable, it SHOULD= be=0A= =A0=A0=A0=A0=A0 refreshed as often as is feasible.=A0 One way to do this is= to=0A= =A0=A0=A0=A0=A0 compute it as a background task so that a fresh value is av= ailable=0A= =A0=A0=A0=A0=A0 when required.=0A= =0A= Peter.=0A= =0A= = From nobody Mon Jan 2 08:19:40 2017 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 80742129569 for ; Sun, 1 Jan 2017 20:59:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 7ij5HvCeGtVl for ; Sun, 1 Jan 2017 20:59:13 -0800 (PST) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 4874D129568 for ; Sun, 1 Jan 2017 20:59:13 -0800 (PST) Received: by mail-yw0-x236.google.com with SMTP id r204so262008541ywb.0 for ; Sun, 01 Jan 2017 20:59:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0ds9xv3dzJpIcVYy73xdWGFt+6wsWqI3cT3SUfotoTc=; b=I+6wXroSreJsk3xzaWH7Hei+GSZM1iFvAHCphdgudzw5gcqEhsCBuMeX4kaqrosGju OWs+9Jn1yui/YIXFRUsLX6sA359oWEaKHnsoTJRMF+wziP8gvRTKUbFbEVj+Kzw6fvE3 1zfppaOsZSXKtL9DLMgncDeZENzgZF1jt5saJCWz9hvmUoIXGNT43tilyBaBTMMud3/b /eezyOwLjfK2Syt0wL6fNN4r8+EvyFJlFHIOByzPxLOFhaP6oqt5pgb2T/sTXaB+nq+v i35iIRH+rNZl2pmoVDnuO5xyMj74W5UGj7LPBMs5T1lTFc/P8jAlAZJWrI/YPlvf8ovZ 1KPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0ds9xv3dzJpIcVYy73xdWGFt+6wsWqI3cT3SUfotoTc=; b=SYAn965IV777d1qmyhMY612aB0IMgqx5VV+MOZM36XlkoWHHAfNF0wHElteluMJuDg srm+H5bAQPTDnoy/n127hKFV+WM6NhG8KvIEhnB7a1AI3eOKZD1eXuXEYyVdb29eyoO3 tU+959cBG/WaV7ixWnnNkWIuP/APbdZAAYhE2b6R0Ik+lUjbPmzeG1NpbRWxteE3CBCf loCm5Si65mZJaPumXFoYFOt8ROJmgxPw1pXGjVIK/8P0FA8HLHHSo2yMlSNFt7A2nGpt 11AbJT3VzwSySf1NeHYt4V7oZIwalcNOgwbVYZi33JSRR7JhR9A8zS+ArhS9GyX19/ef L9KA== X-Gm-Message-State: AIkVDXKip+0uv9gIc45F6xv/epICskqY1wHlQSiZhayQRkXLqm2J+GYECItL9Ay+GL78homoXl961oAuIASerQ== X-Received: by 10.129.164.198 with SMTP id b189mr50105054ywh.294.1483333152372; Sun, 01 Jan 2017 20:59:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.44.141 with HTTP; Sun, 1 Jan 2017 20:59:11 -0800 (PST) Received: by 10.37.44.141 with HTTP; Sun, 1 Jan 2017 20:59:11 -0800 (PST) In-Reply-To: References: From: Hugo Krawczyk Date: Sun, 1 Jan 2017 23:59:11 -0500 Message-ID: To: Adam Langley Content-Type: multipart/alternative; boundary=94eb2c129c78a17ddc0545156949 Archived-At: X-Mailman-Approved-At: Mon, 02 Jan 2017 08:19:38 -0800 Cc: tls@ietf.org Subject: Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)DHE public values be fresh X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 02 Jan 2017 04:59:16 -0000 --94eb2c129c78a17ddc0545156949 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Typo correction below. On Jan 1, 2017 12:43 PM, "Hugo Krawczyk" wrote: There is more than one way to "backdoor" the use of DH (i.e., to not enforce forward secrecy) and some of these ways are completely undetectable (in particular, they would not repeat DH values). One has to be careful not to give a false sense of security by the illusion that not detecting DH repetition guarantees forward secrecy (FS). The value of a MUST NOT that cannot be enforced is debatable even though it may serve as a strong message to implementers that FS is an important property to comply with (which is the domain of SHOULD). Another consideration is that there are applications where FS is of little value, e.g. anything where the requirement is authentication and not secrecy or where the secrecy requirement itself is ephemeral. Just to make it clear: I have been a supporter and promoter of forward secrecy since the early days of IPsec and I think it is the most important new feature of TLS 1.3, so the above should be understood as lukewarm feelings towards FS I guess it is clear from the context but the above sentence misses a NOT: "The above should NOT be understood as..." . Just that we have to understand that we cannot have an "anti-backdoor" guarantee and that there may be applications with legitimate reasons not to use FS. On Sat, Dec 31, 2016 at 1:36 PM, Adam Langley wrote: > (Note: I'm reordering Brian's paragraphs here so that I can address > all of those on a single topic at a time.) > > On Thu, Dec 29, 2016 at 4:29 PM, Brian Smith wrote= : > > It would make self-hosting a small that can survive a spike in traffic > > ("slashdot effect") more difficult, thus encouraging sites to use > > CDNs, which decrease the integrity, confidentiality, and privacy > > properties of all connections between the client and the origin > > server. Unfortunately I don't know how to quantify that. > > > > Another unintended consequence is that it makes the PSK modes > > relatively more attractive. For some very small devices doing ECDH > > agreement on every connection and only doing a occasionally doing a > > ECDH keygen could be at the edge of their performance/power limits, > > and needing to do the ECDH keygen for every connection could easily > > make using ECDH prohibitive. OTOH, we don't want these devices to use > > have a fixed ECDH key burned into their ROM, or similar, either. > > > > Another unintended consequence is that it makes resumption (formulated > > as a sort of server-generated PSK in TLS 1.3) more necessary. Although > > many implementations will probably implement resumption, I think there > > are a lot of cases where one might prefer to avoid implementing and/or > > enabling it. Also, even when it is enabled, making ECDH more expensive > > relative to PSK/resumption would encourage building more complex > > server software to distribute PSKs across machines. And/or the server > > may choose to reuse PSKs longer. And/or the server may choose to use > > the non-ECDHE form of PSK-based resumption (IIUC). Again, though, I > > can't quantify the effect here. > > > > With all this in mind, absent other information. In the case of > > servers hosting websites, I do think a limit of less than a minute is > > reasonable. However, I think for the small device (IoT) case, the > > limit should be longer, perhaps even hours. > > In practice, at the moment, sites are generally using RSA > certificates, so a small device getting slashdotted would be dominated > by the RSA signing costs rather than the ECDHE. > > But let's posit EdDSA certificates, where ECDHE generation might then > account for a 1/3 of the handshake cost. You make a good point that we > don't want to push low-end devices into PSK. Also, small devices are > less likely to be able to afford the tables that make fixed-base > operations fast. > > I don't actually object to allowing servers to cache a ECDHE public > value for a small about of time. (QUIC currently does so for 30 > seconds.) But I was worried about the arguments over the duration if I > specified one :) > > Consider the motivations here: > > 1) We know that some implementations have gotten this wrong with TLS > 1.2 and cached values for far too long. Presumably if they were to be > naively extended to TLS 1.3 this issue would carry over. > > 2) We probably disagree with this banking industry desire to be able > to backdoor their TLS connections, but we're not the police and fixing > DH values is probably how they would do it. If it's going to be A > Thing then it's much more likely that things will get misconfigured > and it'll be enabled in places where it shouldn't be. If we have no > detection mechanism then what we'll probably end up with is a Blackhat > talk in a few years time about how x% of banks botched forward > security at their frontends. > > Say that a value of an hour makes sense for some device and we feel > that an hour's forward-security window is reasonable for security. The > issue is that it significantly diminishes our detection ability > because clients need to remember more than an hour's worth of values > and I don't know if we can dedicate that amount of storage to this. > > Since I think the utility of this falls off as a reciprocal, I'll try > making a concrete suggestion for a time limit: 10 seconds. > > >> Also, this cost doesn't seem too high: 85.6% of servers /don't/ reuse > >> values and manage fine today. The generation of (EC)DH public values > >> is also a fixed-based operation and thus can be much faster than DH > >> key-agreement. > > > > According to the paper, a large majority of servers in the Alexa top > > 1M are reusing keys. That 14.4% number is a fraction of the 80% > > servers consistently in the Alexa top 1M that use browser-trusted > > certificates and that use ECDHE. IIUC, approximately 20% of servers in > > the Alexa top 1M that use browser-trusted certificates are using RSA > > key exchange, which means they are also reusing the same key for every > > connection. Also, according to the paper, more than half of servers > > aren't using TLS or aren't using browser-trusted certificates, which > > means that web browser connections to them are likely using the same > > NULL key. > > Thanks for pointing that out. I thought that saying "14.4%" and so on > was reasonable because it's a prevalence and we can assume that if > other sites did enable (EC)DHE then they would probably make the same > mistakes at a similar rate. But then I subtracted it from 100 and that > really doesn't make sense. > > > Also, the Alexa top 1M isn't representative of every use of TLS, but > > rather only one kind of application. > > > >> Lastly, some have proposed[2] (EC)DH reuse as a mechanism for enabling > >> TLS connections to be decrypted and monitored by a middlebox. TLS is > >> not designed to be decrypted by third-parties=E2=80=94that's kind of t= he > >> point. Thus anyone doing this should not be surprised to hit a few > >> MUST NOTs and, potentially, to have to configure implementations to > >> allow such a deployment. > > > > The (presumably) accidental reuse of keys for long periods of time is > > bad, and this MitM idea is even worse. But, if reuse were made a MUST > > NOT, wouldn't such systems just use a different, perhaps worse, more > > complex, and undetectable mechanism, like the one Dan Brown suggested > > in the earlier thread? I think we should assume that while we may be > > able to help prevent the former accidental badness with such a rule, > > such a mechanism probably isn't going to have much effect on the > > latter intentional badness. > > I much prefer people who are going to backdoor their TLS to use DH as > the mechanism rather than something less detectable. I don't expect a > MUST NOT will slow them down at all. I just want to ensure that this > doesn't accidently carry into 1.3, and that any unofficial backdoor > mechanism needed by some organisations doesn't inadvertently get > enabled more widely than planned. > > > Cheers > > AGL > > -- > Adam Langley agl@imperialviolet.org https://www.imperialviolet.org > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c129c78a17ddc0545156949 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Typo correction below.=C2=A0

On Jan 1, 2017 12:43 PM, "Hugo K= rawczyk" <hugo@ee.technio= n.ac.il> wrote:
There is more than one way to "backdoor"= the use of DH (i.e., to not enforce forward secrecy) and some of these way= s are completely undetectable (in particular, they would not repeat DH valu= es). One has to be careful not to give a false sense of security by the ill= usion that not detecting DH repetition guarantees forward secrecy (FS). The= value of a MUST NOT that cannot be enforced is debatable even though it ma= y serve as a strong message to implementers that FS is an important propert= y to comply with (which is the domain of SHOULD). Another consideration is = that there are applications where FS is of little value, e.g. anything wher= e the requirement is authentication and not secrecy or where the secrecy re= quirement itself is ephemeral.

Just to make it clea= r: I have been a supporter and promoter of forward secrecy since the early = days of IPsec and I think it is the most important new feature of TLS 1.3, = so the above should be understood as lukewarm feelings towards FS

I guess it is clear from the con= text but the above sentence misses a NOT: "The above should NOT be und= erstood as..."=C2=A0

. Just that we have to understand that we cannot have an &q= uot;anti-backdoor" guarantee and that there may be applications with l= egitimate reasons not to use FS.

On Sat, Dec 31, = 2016 at 1:36 PM, Adam Langley <agl@imperialviolet.org> = wrote:
(Note: I'm reordering Brian= 9;s paragraphs here so that I can address
all of those on a single topic at a time.)

On Thu, Dec 29, 2016 at 4:29 PM, Brian Smith <brian@briansmith.org> wrote:
> It would make self-hosting a small that can survive a spike in traffic=
> ("slashdot effect") more difficult, thus encouraging sites t= o use
> CDNs, which decrease the integrity, confidentiality, and privacy
> properties of all connections between the client and the origin
> server. Unfortunately I don't know how to quantify that.
>
> Another unintended consequence is that it makes the PSK modes
> relatively more attractive. For some very small devices doing ECDH
> agreement on every connection and only doing a occasionally doing a > ECDH keygen could be at the edge of their performance/power limits, > and needing to do the ECDH keygen for every connection could easily > make using ECDH prohibitive. OTOH, we don't want these devices to = use
> have a fixed ECDH key burned into their ROM, or similar, either.
>
> Another unintended consequence is that it makes resumption (formulated=
> as a sort of server-generated PSK in TLS 1.3) more necessary. Although=
> many implementations will probably implement resumption, I think there=
> are a lot of cases where one might prefer to avoid implementing and/or=
> enabling it. Also, even when it is enabled, making ECDH more expensive=
> relative to PSK/resumption would encourage building more complex
> server software to distribute PSKs across machines. And/or the server<= br> > may choose to reuse PSKs longer. And/or the server may choose to use > the non-ECDHE form of PSK-based resumption (IIUC). Again, though, I > can't quantify the effect here.
>
> With all this in mind, absent other information. In the c= ase of
> servers hosting websites, I do think a limit of less than a minute is<= br> > reasonable. However, I think for the small device (IoT) case, the
> limit should be longer, perhaps even hours.

In practice, at the moment, sites are generally using RSA
certificates, so a small device getting slashdotted would be dominated
by the RSA signing costs rather than the ECDHE.

But let's posit EdDSA certificates, where ECDHE generation might then account for a 1/3 of the handshake cost. You make a good point that we
don't want to push low-end devices into PSK. Also, small devices are less likely to be able to afford the tables that make fixed-base
operations fast.

I don't actually object to allowing servers to cache a ECDHE public
value for a small about of time. (QUIC currently does so for 30
seconds.) But I was worried about the arguments over the duration if I
specified one :)

Consider the motivations here:

1) We know that some implementations have gotten this wrong with TLS
1.2 and cached values for far too long. Presumably if they were to be
naively extended to TLS 1.3 this issue would carry over.

2) We probably disagree with this banking industry desire to be able
to backdoor their TLS connections, but we're not the police and fixing<= br> DH values is probably how they would do it. If it's going to be A
Thing then it's much more likely that things will get misconfigured
and it'll be enabled in places where it shouldn't be. If we have no=
detection mechanism then what we'll probably end up with is a Blackhat<= br> talk in a few years time about how x% of banks botched forward
security at their frontends.

Say that a value of an hour makes sense for some device and we feel
that an hour's forward-security window is reasonable for security. The<= br> issue is that it significantly diminishes our detection ability
because clients need to remember more than an hour's worth of values and I don't know if we can dedicate that amount of storage to this.

Since I think the utility of this falls off as a reciprocal, I'll try making a concrete suggestion for a time limit: 10 seconds.

>> Also, this cost doesn't seem too high: 85.6% of servers /don&#= 39;t/ reuse
>> values and manage fine today. The generation of (EC)DH public valu= es
>> is also a fixed-based operation and thus can be much faster than D= H
>> key-agreement.
>
> According to the paper, a large majority of servers in the Alexa top > 1M are reusing keys. That 14.4% number is a fraction of the 80%
> servers consistently in the Alexa top 1M that use browser-trusted
> certificates and that use ECDHE. IIUC, approximately 20% of servers in=
> the Alexa top 1M that use browser-trusted certificates are using RSA > key exchange, which means they are also reusing the same key for every=
> connection. Also, according to the paper, more than half of servers > aren't using TLS or aren't using browser-trusted certificates,= which
> means that web browser connections to them are likely using the same > NULL key.

Thanks for pointing that out. I thought that saying "14.4%"= ; and so on
was reasonable because it's a prevalence and we can assume that if
other sites did enable (EC)DHE then they would probably make the same
mistakes at a similar rate. But then I subtracted it from 100 and that
really doesn't make sense.

> Also, the Alexa top 1M isn't representative of every use of TLS, b= ut
> rather only one kind of application.
>
>> Lastly, some have proposed[2] (EC)DH reuse as a mechanism for enab= ling
>> TLS connections to be decrypted and monitored by a middlebox. TLS = is
>> not designed to be decrypted by third-parties=E2=80=94that's k= ind of the
>> point. Thus anyone doing this should not be surprised to hit a few=
>> MUST NOTs and, potentially, to have to configure implementations t= o
>> allow such a deployment.
>
> The (presumably) accidental reuse of keys for long periods of time is<= br> > bad, and this MitM idea is even worse. But, if reuse were made a MUST<= br> > NOT, wouldn't such systems just use a different, perhaps worse, mo= re
> complex, and undetectable mechanism, like the one Dan Brown suggested<= br> > in the earlier thread? I think we should assume that while we may be > able to help prevent the former accidental badness with such a rule, > such a mechanism probably isn't going to have much effect on the > latter intentional badness.

I much prefer people who are going to backdoor their TLS to use DH a= s
the mechanism rather than something less detectable. I don't expect a MUST NOT will slow them down at all. I just want to ensure that this
doesn't accidently carry into 1.3, and that any unofficial backdoor
mechanism needed by some organisations doesn't inadvertently get
enabled more widely than planned.


Cheers

AGL

--
Adam Langley ag= l@imperialviolet.org https://www.imperialviolet.org

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


--94eb2c129c78a17ddc0545156949-- From nobody Mon Jan 2 08:58:47 2017 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 A28181296C8 for ; Mon, 2 Jan 2017 08:58:45 -0800 (PST) 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, 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 SZZgjOEIQvhW for ; Mon, 2 Jan 2017 08:58:44 -0800 (PST) Received: from mail-wj0-x229.google.com (mail-wj0-x229.google.com [IPv6:2a00:1450:400c:c01::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 CE71F12944B for ; Mon, 2 Jan 2017 08:58:43 -0800 (PST) Received: by mail-wj0-x229.google.com with SMTP id sd9so243306569wjb.1 for ; Mon, 02 Jan 2017 08:58:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=potxK2iGQg5ktnSTDMDLLiPGBgtRydzxSbjKTNcICVA=; b=o3l05ZM4kck3sRu6eFXlRRswqohcVIq8tUQ//CqANjSKILl/5Ln4Vyh0aQ903kFj/L V8abOQBVZ3YaLEgIDFO9gCnbyz3LU79qMQ9yuaxvoVih/rE4FIDK1+CQArD6olVlediR YU2hCX+uhMldHtZ/47KzcQklRxB++vrzUdiVZIkQGQqqHelrIksMTswW93RpJQaMurpj VIyAhj5m+a06lEiyt7ll2wUOtAX4s8FT6z9hsGy1JJAKyxip8U2LbkdxwBexsik5hrgb WfhKct6KtK0soF7PJex/wD40P7QF6v2EbYuaTPmLqks4Rr/SqhFJfi3UUuFS65+qMDk2 NJaQ== 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:date:references:to :in-reply-to:message-id; bh=potxK2iGQg5ktnSTDMDLLiPGBgtRydzxSbjKTNcICVA=; b=BYCvGOhtr5iSc457hHer1Dk9azacmhvXw3qdxBfxaHyt+pPmN8s6ks25EJLrO1UBK3 y1kKtRcfESbIcXubLlgBdl3ajzAvbQH0uAUuC1c8D3D6yfNIlPOKI8usM1RPqCdd19Lx hIpG0TT8DTSOmxKjRABLS/JHSnWr4JE6oT/SYM+4TfBocl2CPCQJ46w3hkT3V4lc1xhn hAe7iZKJYl9FuvTARDQSr6iyuo4s41F8jrZ1VuZAm1OPQGOqobWkPRVYh5uZ6yMdiznN IYBwhRH7VTBsgK6Dmb9hBq4ELa+9ljK9kLwAUUnYo7FSQ0avoie8ZMit2BzBkMoq011t cUug== X-Gm-Message-State: AIkVDXIFDHgvkJUDudtZtOtE4khYqeSVXG+K3d3msgVdTXlBsRJ8refd+0Q9HSWrc9V7hQ== X-Received: by 10.194.0.70 with SMTP id 6mr39455237wjc.215.1483376321869; Mon, 02 Jan 2017 08:58:41 -0800 (PST) Received: from [192.168.137.200] ([109.253.138.8]) by smtp.gmail.com with ESMTPSA id b3sm88778836wjy.40.2017.01.02.08.58.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Jan 2017 08:58:41 -0800 (PST) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_42424D8A-69CA-41CB-A07E-64B0CEA65A6D" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 2 Jan 2017 18:58:36 +0200 References: <1483330131409.25713@cs.auckland.ac.nz> To: "" In-Reply-To: <1483330131409.25713@cs.auckland.ac.nz> Message-Id: <5542029D-293A-44F5-9A11-62F5C47A4BA5@gmail.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)DHE public values be fresh X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 02 Jan 2017 16:58:45 -0000 --Apple-Mail=_42424D8A-69CA-41CB-A07E-64B0CEA65A6D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 31 Dec 2016, at 20:36, Adam Langley wrote: > Consider the motivations here: >=20 > 1) We know that some implementations have gotten this wrong with TLS > 1.2 and cached values for far too long. Presumably if they were to be > naively extended to TLS 1.3 this issue would carry over. >=20 > 2) We probably disagree with this banking industry desire to be able > to backdoor their TLS connections, but we're not the police and fixing > DH values is probably how they would do it. If it's going to be A > Thing then it's much more likely that things will get misconfigured > and it'll be enabled in places where it shouldn't be. If we have no > detection mechanism then what we'll probably end up with is a Blackhat > talk in a few years time about how x% of banks botched forward > security at their frontends. >=20 > Say that a value of an hour makes sense for some device and we feel > that an hour's forward-security window is reasonable for security. The > issue is that it significantly diminishes our detection ability > because clients need to remember more than an hour's worth of values > and I don't know if we can dedicate that amount of storage to this. >=20 > Since I think the utility of this falls off as a reciprocal, I'll try > making a concrete suggestion for a time limit: 10 seconds. I like this number, because that=E2=80=99s the number I chose when I = implemented ECDH caching in Check Point=E2=80=99s TLS library. It makes = key generation rare enough that it makes no difference for server load = in any normal hardware, and frequent enough that if you destroy the keys = after they are last used then attackers have a very narrow window of = opportunity to get your keys. Especially if they need to get a warrant. = IoT may be abnormal hardware in that regard. Still, if we want to accommodate the banking industry (or whatever part = of it we=E2=80=99ve talked to in Seoul), then they need to be able to = tell based on a timestamp which private key was used for that handshake. = With 60 seconds key changes are rare enough that there are at most two = possibilities which I think is manageable. With 10 seconds clock skew = can ruin your system. But I realize I=E2=80=99m bike shedding here. On 2 Jan 2017, at 6:09, Peter Gutmann wrote: > Hugo Krawczyk writes: >=20 >> there may be applications with legitimate reasons not to use FS.=20 >=20 > It's not so much reasons not to use FS (well, there are some = specialised cases > where people want to do that as well), it's reasons to reuse (EC)DH = values. > This isn't something that was ever mentioned in the spec, it's what = developers > have implemented themselves in order to deal with high-load = conditions. This > also means that no matter what the spec might say in the future, if = you've got > a developer facing a situation where they need 480% of available CPU = to > service requests then they're going to do things like cache (EC)DH, = regardless > of what the spec says. So making it a MUST NOT will end up as what = someone on > PKIX once described as "workgroup posturing". Better to include an = advisory > note on using it, Well, it just so happens=E2=80=A6 https://github.com/tlswg/tls13-spec/pull/768/files = Yoav --Apple-Mail=_42424D8A-69CA-41CB-A07E-64B0CEA65A6D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 31 Dec 2016, at 20:36, Adam Langley <agl@imperialviolet.org> wrote:

Consider the = motivations here:

1) We know that some = implementations have gotten this wrong with TLS
1.2 and = cached values for far too long. Presumably if they were to be
naively extended to TLS 1.3 this issue would carry over.

2) We probably disagree with this banking = industry desire to be able
to backdoor their TLS = connections, but we're not the police and fixing
DH values = is probably how they would do it. If it's going to be A
Thing then it's much more likely that things will get = misconfigured
and it'll be enabled in places where it = shouldn't be. If we have no
detection mechanism then what = we'll probably end up with is a Blackhat
talk in a few = years time about how x% of banks botched forward
security = at their frontends.

Say that a value of an = hour makes sense for some device and we feel
that an = hour's forward-security window is reasonable for security. The
issue is that it significantly diminishes our detection = ability
because clients need to remember more than an = hour's worth of values
and I don't know if we can dedicate = that amount of storage to this.

Since I = think the utility of this falls off as a reciprocal, I'll try
making a concrete suggestion for a time limit: 10 seconds.

I like this number, because that=E2=80=99s the number I chose = when I implemented ECDH caching in Check Point=E2=80=99s TLS library. It = makes key generation rare enough that it makes no difference for server = load in any normal hardware, and frequent enough that if you destroy the = keys after they are last used then attackers have a very narrow window = of opportunity to get your keys. Especially if they need to get a = warrant. IoT may be abnormal hardware in that regard.

Still, if we want to = accommodate the banking industry (or whatever part of it we=E2=80=99ve = talked to in Seoul), then they need to be able to tell based on a = timestamp which private key was used for that handshake. With 60 seconds = key changes are rare enough that there are at most two possibilities = which I think is manageable. With 10 seconds clock skew can ruin your = system.  But I realize I=E2=80=99m bike shedding here.

On 2 Jan 2017, at = 6:09, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:

Hugo Krawczyk <hugo@ee.technion.ac.il> writes:

there may be = applications with legitimate reasons not to use FS.

It's not so much reasons not to = use FS (well, there are some specialised cases
where = people want to do that as well), it's reasons to reuse (EC)DH values.
This isn't something that was ever mentioned in the spec, = it's what developers
have implemented themselves in order = to deal with high-load conditions.  This
also means = that no matter what the spec might say in the future, if you've got
a developer facing a situation where they need 480% of = available CPU to
service requests then they're going to do = things like cache (EC)DH, regardless
of what the spec = says.  So making it a MUST NOT will end up as what someone on
PKIX once described as "workgroup posturing".  Better to = include an advisory
note on using = it,

Well, it just so = happens=E2=80=A6

Yoav

= --Apple-Mail=_42424D8A-69CA-41CB-A07E-64B0CEA65A6D-- From nobody Mon Jan 2 09:12:52 2017 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 ACADA1296D6 for ; Mon, 2 Jan 2017 09:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 VqapUh1CSQ3X for ; Mon, 2 Jan 2017 09:12:48 -0800 (PST) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 83CF41296D2 for ; Mon, 2 Jan 2017 09:12:48 -0800 (PST) Received: by mail-yw0-x22d.google.com with SMTP id t125so271266923ywc.1 for ; Mon, 02 Jan 2017 09:12:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FVpbYGcChhFwXZUHWQZ4j49GPdXoTnpRXIUSoGB5miw=; b=VFxUZjN2eQreEMau4e7So/qB8kZyVvdvIvpBHri3q3sIyQ+LtkqrLJfhGrq7tyQ+mu 59RHA1+11l0q4eU9Ure2Zi2i+wqh97yki4p8aW7U+MZCoTTU8yQd7PhqBeQ53/reTWmY 7RleUwV8vX9Kw7600Db2gCKkW6ntImzAshaotYJyUpiVxhIKFJCW/dGvzKtegLS0cGG3 g8+tycwneVj7fJ4EBmt2LdW+iKfvt2Zg/CnFaaxOZ4rq6k7U4XFuPGQoY7EDGcMt96J3 63C9aWDQ2wOpuXUl5oZqx6h53AIvHR5AHnUdnensuRoluwlZDpWg+vz8v9gX/2go6fQS zH7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FVpbYGcChhFwXZUHWQZ4j49GPdXoTnpRXIUSoGB5miw=; b=YyuNKY7y+0wA/NjW/DlJo+2Ohz9wm/n7djyVKNgqKPMHh3ClKCH2N0K72Tx27zXH0M s3LipfuXHgO4mVwAOAyL0o3UC/kNDUlbxd9xhqvRdIn8XFI9QgryZy6EWl9fONPoZc6T PiwTNMd2jkNBtMxfC7gK0dJ9a/fetQb5+iDsriZwrTJSPxccijkMiLGcANsoq/Y3fAKM dlQkN1vYep4tsA2nhxhK1DLLhPia1Ag5asD+fWNI2it2pIJAEgSvTgEIleeHWKaNvkyF yTwUIKiApK6upvCNJiTiXw31TR7qby/amwegcGfJiS5sh1yEOi/nmVkaCR9Yr5vT0FeW lm4Q== X-Gm-Message-State: AIkVDXL1RZtxYYJZOhbcuALkBVZmrBVfc/KK3Z5yF2zR+OcwTqgVDFka+j0REl2Aef4XXfRdYb/+S8c5EMQ7bw== X-Received: by 10.129.121.1 with SMTP id u1mr54409985ywc.146.1483377167793; Mon, 02 Jan 2017 09:12:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.164.210 with HTTP; Mon, 2 Jan 2017 09:12:07 -0800 (PST) In-Reply-To: <5542029D-293A-44F5-9A11-62F5C47A4BA5@gmail.com> References: <1483330131409.25713@cs.auckland.ac.nz> <5542029D-293A-44F5-9A11-62F5C47A4BA5@gmail.com> From: Eric Rescorla Date: Mon, 2 Jan 2017 09:12:07 -0800 Message-ID: To: Yoav Nir Content-Type: multipart/alternative; boundary=94eb2c0a8f8227b25705451fa918 Archived-At: Cc: "" Subject: Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)DHE public values be fresh X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 02 Jan 2017 17:12:50 -0000 --94eb2c0a8f8227b25705451fa918 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yoav, Thanks for pointing to this PR. Clearly we're only going to land one of these. One thing I wanted to note, as discussed in the comments on that PR, is that at least some of the proofs of security of TLS 1.3 assume that both sides use fresh DH shares. In TLS 1.3, of course, the nonces provide freshness [0], s= o intuitively reuse of DH shares should only threaten FS, however, an claims that that's actually the case should come with some analytic support. If reuse i= s forbidden than no such support is needed. -Ekr [0] See SIGMA page 24 for a bit more on this topic. On Mon, Jan 2, 2017 at 8:58 AM, Yoav Nir wrote: > On 31 Dec 2016, at 20:36, Adam Langley wrote: > > Consider the motivations here: > > 1) We know that some implementations have gotten this wrong with TLS > 1.2 and cached values for far too long. Presumably if they were to be > naively extended to TLS 1.3 this issue would carry over. > > 2) We probably disagree with this banking industry desire to be able > to backdoor their TLS connections, but we're not the police and fixing > DH values is probably how they would do it. If it's going to be A > Thing then it's much more likely that things will get misconfigured > and it'll be enabled in places where it shouldn't be. If we have no > detection mechanism then what we'll probably end up with is a Blackhat > talk in a few years time about how x% of banks botched forward > security at their frontends. > > Say that a value of an hour makes sense for some device and we feel > that an hour's forward-security window is reasonable for security. The > issue is that it significantly diminishes our detection ability > because clients need to remember more than an hour's worth of values > and I don't know if we can dedicate that amount of storage to this. > > Since I think the utility of this falls off as a reciprocal, I'll try > making a concrete suggestion for a time limit: 10 seconds. > > > I like this number, because that=E2=80=99s the number I chose when I impl= emented > ECDH caching in Check Point=E2=80=99s TLS library. It makes key generatio= n rare > enough that it makes no difference for server load in any normal hardware= , > and frequent enough that if you destroy the keys after they are last used > then attackers have a very narrow window of opportunity to get your keys. > Especially if they need to get a warrant. IoT may be abnormal hardware in > that regard. > > Still, if we want to accommodate the banking industry (or whatever part o= f > it we=E2=80=99ve talked to in Seoul), then they need to be able to tell b= ased on a > timestamp which private key was used for that handshake. With 60 seconds > key changes are rare enough that there are at most two possibilities whic= h > I think is manageable. With 10 seconds clock skew can ruin your system. > But I realize I=E2=80=99m bike shedding here. > > On 2 Jan 2017, at 6:09, Peter Gutmann wrote: > > Hugo Krawczyk writes: > > there may be applications with legitimate reasons not to use FS. > > > It's not so much reasons not to use FS (well, there are some specialised > cases > where people want to do that as well), it's reasons to reuse (EC)DH value= s. > This isn't something that was ever mentioned in the spec, it's what > developers > have implemented themselves in order to deal with high-load conditions. > This > also means that no matter what the spec might say in the future, if you'v= e > got > a developer facing a situation where they need 480% of available CPU to > service requests then they're going to do things like cache (EC)DH, > regardless > of what the spec says. So making it a MUST NOT will end up as what > someone on > PKIX once described as "workgroup posturing". Better to include an > advisory > note on using it, > > > Well, it just so happens=E2=80=A6 > https://github.com/tlswg/tls13-spec/pull/768/files > > Yoav > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --94eb2c0a8f8227b25705451fa918 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yoav,

Thanks for pointing to this PR. C= learly we're only going to land one of these.

= One thing I wanted to note, as discussed in the comments on that PR, is tha= t at
least some of the proofs of security of TLS 1.3 assume that = both sides use
fresh DH shares. In TLS 1.3, of course, the nonces= provide freshness [0], so
intuitively reuse of DH shares should = only threaten FS, however, an claims that
that's actually the= case should come with some analytic support. If reuse is
forbidd= en than no such support is needed.

-Ekr
=
[0] See SIGMA page 24 for a bit more on this topic.


On Mo= n, Jan 2, 2017 at 8:58 AM, Yoav Nir <ynir.ietf@gmail.com> = wrote:
On 31 Dec 2016, at 20:36, Adam Langley <agl@imperialviolet.org> wro= te:

Consider the motivations = here:

1) We know that some implementations have gotten this wrong wi= th TLS
1.2 and cached values for far too long. Presumably if they were t= o be
naively extended to TLS 1.3 this issue would carry over.

2) = We probably disagree with this banking industry desire to be able
to bac= kdoor their TLS connections, but we're not the police and fixing
DH = values is probably how they would do it. If it's going to be A
Thing= then it's much more likely that things will get misconfigured
and i= t'll be enabled in places where it shouldn't be. If we have no
d= etection mechanism then what we'll probably end up with is a Blackhattalk in a few years time about how x% of banks botched forward
securit= y at their frontends.

Say that a value of an hour makes sense for so= me device and we feel
that an hour's forward-security window is reas= onable for security. The
issue is that it significantly diminishes our d= etection ability
because clients need to remember more than an hour'= s worth of values
and I don't know if we can dedicate that amount of= storage to this.

Since I think the utility of this falls off as a r= eciprocal, I'll try
making a concrete suggestion for a time limit: 1= 0 seconds.

I like this number, b= ecause that=E2=80=99s the number I chose when I implemented ECDH caching in= Check Point=E2=80=99s TLS library. It makes key generation rare enough tha= t it makes no difference for server load in any normal hardware, and freque= nt enough that if you destroy the keys after they are last used then attack= ers have a very narrow window of opportunity to get your keys. Especially i= f they need to get a warrant. IoT may be abnormal hardware in that regard.<= /div>

Still, if we want to accommodate the banking indus= try (or whatever part of it we=E2=80=99ve talked to in Seoul), then they ne= ed to be able to tell based on a timestamp which private key was used for t= hat handshake. With 60 seconds key changes are rare enough that there are a= t most two possibilities which I think is manageable. With 10 seconds clock= skew can ruin your system.=C2=A0 But I realize I=E2=80=99m bike shedding h= ere.

On 2 Jan 2017, at 6:09, Peter Gutm= ann <pgut= 001@cs.auckland.ac.nz> wrote:

Hugo Krawczyk <hugo@ee.technion.ac.il> writes:

there may be applications with legitimate reasons not t= o use FS.

It's not so much reasons not to use FS (= well, there are some specialised cases
where people want to do that as w= ell), it's reasons to reuse (EC)DH values.
This isn't something = that was ever mentioned in the spec, it's what developers
have imple= mented themselves in order to deal with high-load conditions.=C2=A0 Thisalso means that no matter what the spec might say in the future, if you= 9;ve got
a developer facing a situation where they need 480% of availabl= e CPU to
service requests then they're going to do things like cache= (EC)DH, regardless
of what the spec says.=C2=A0 So making it a MUST NOT= will end up as what someone on
PKIX once described as "workgroup p= osturing".=C2=A0 Better to include an advisory
note on using it,

Well, it just so happens=E2=80= =A6

Yoav


__= _____________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--94eb2c0a8f8227b25705451fa918-- From nobody Mon Jan 2 09:50:02 2017 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 EB1131293EB; Mon, 2 Jan 2017 09:49:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148337939795.21889.6405945052916597254.idtracker@ietfa.amsl.com> Date: Mon, 02 Jan 2017 09:49:57 -0800 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-iana-registry-updates-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 02 Jan 2017 17:49:58 -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 of the IETF. Title : D/TLS IANA Registry Updates Authors : Joe Salowey Sean Turner Filename : draft-ietf-tls-iana-registry-updates-00.txt Pages : 11 Date : 2017-01-02 Abstract: This document changes the IANA registry policy for a number of registries related to DTLS and TLS, renames some of the registries for consistency, and adds notes to many of the registries. As a result, this document updates many RFCs (see updates header). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tls-iana-registry-updates-00 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 Jan 2 09:52:04 2017 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 4D1ED1293EB for ; Mon, 2 Jan 2017 09:52:03 -0800 (PST) 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 (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 xJeQiWXgUEHB for ; Mon, 2 Jan 2017 09:52:01 -0800 (PST) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 7FFEF1200A0 for ; Mon, 2 Jan 2017 09:52:01 -0800 (PST) Received: by mail-qt0-x232.google.com with SMTP id k15so206544317qtg.3 for ; Mon, 02 Jan 2017 09:52:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=8yaAJqFuuhNnxR+XwoAbRpWdZNhDTIVdaQDowl/qUyk=; b=PLcq+odh1K6m0xBWjH7MNA7UEnszjE0W1cB5sUnw9/Ml9OTxmxZtUEms07Oss63ML1 Mo8LZlb8lnmh0LVKIbOrf5JVqOh1FEScgc4IcCYFGE+hGWplB9TqplCMaql58j7uw5x5 K6WC4eJDbkeFPbzJAWNdowVU/yyFRZf8p3+0Y= 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 :content-transfer-encoding:message-id:references:to; bh=8yaAJqFuuhNnxR+XwoAbRpWdZNhDTIVdaQDowl/qUyk=; b=nsNiyNR4fFMgzCpe2XmbVtSjn8B+iWYdiq8+04p45KNWOYDSWMR6sLVW4ux2CgmzT6 oSF2eCIeAGnetLCv0WpdsWU3bUcHja44GX7nu5ZXU+mMA8WvDr/FZ3UdB6wWJ6xUiHLN uOrpyU5So4LL60ZUYgR11Hpk0k5g9bwDGj621vlm/jHiIei4h7YfoxC6KaLrkuITJHaM IkWCA6lyLr1HzfWCa0l9j5Qg0kZtm4VsoL1l0JQfuKOvZHOmDMUxVUOh/+emJ3AnVKvO mTC2KuQNNHLMpW0Q2RXv8UENddJjkU///QjcqfmoKgcxHe0n+s5O7GUGat8QeGkq/hmq c/VQ== X-Gm-Message-State: AIkVDXKrhmWaLwZEYfTlbthzgPLX2Xi/4cYKCOe/GBoJnJosXvxcfVdCFutqicGExp85ew== X-Received: by 10.200.42.202 with SMTP id c10mr54204422qta.251.1483379520566; Mon, 02 Jan 2017 09:52:00 -0800 (PST) Received: from [172.16.0.92] (pool-173-73-120-80.washdc.east.verizon.net. [173.73.120.80]) by smtp.gmail.com with ESMTPSA id g13sm41933162qtg.15.2017.01.02.09.51.59 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 02 Jan 2017 09:52:00 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <148337939795.21889.6405945052916597254.idtracker@ietfa.amsl.com> Date: Mon, 2 Jan 2017 12:51:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4DF4AFFF-D43C-4887-8B4C-B0BCF172C01C@sn3rd.com> References: <148337939795.21889.6405945052916597254.idtracker@ietfa.amsl.com> To: "" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-iana-registry-updates-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 02 Jan 2017 17:52:03 -0000 Uploaded and approved this draft as a WG draft after receiving approval = from our AD. The repo for this draft can be found at: https://github.com/tlswg/draft-ietf-tls-iana-registry-updates PR=E2=80=99s welcome. spt > On Jan 2, 2017, at 12:49, internet-drafts@ietf.org wrote: >=20 >=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 of the IETF. >=20 > Title : D/TLS IANA Registry Updates > Authors : Joe Salowey > Sean Turner > Filename : draft-ietf-tls-iana-registry-updates-00.txt > Pages : 11 > Date : 2017-01-02 >=20 > Abstract: > This document changes the IANA registry policy for a number of > registries related to DTLS and TLS, renames some of the registries > for consistency, and adds notes to many of the registries. As a > result, this document updates many RFCs (see updates header). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-tls-iana-registry-updates-00 >=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 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Jan 2 10:52:22 2017 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 B567B12951A for ; Mon, 2 Jan 2017 10:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.1] 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 jgmXZhlVncQy for ; Mon, 2 Jan 2017 10:52:19 -0800 (PST) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id DA10B129447 for ; Mon, 2 Jan 2017 10:52:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 1EFB2145CD; Mon, 2 Jan 2017 20:52:17 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id FSICgCnglLBM; Mon, 2 Jan 2017 20:52:16 +0200 (EET) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id C1544C4; Mon, 2 Jan 2017 20:52:16 +0200 (EET) Date: Mon, 2 Jan 2017 20:52:06 +0200 From: Ilari Liusvaara To: Yoav Nir Message-ID: <20170102185206.GA19750@LK-Perkele-V2.elisa-laajakaista.fi> References: <1483330131409.25713@cs.auckland.ac.nz> <5542029D-293A-44F5-9A11-62F5C47A4BA5@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5542029D-293A-44F5-9A11-62F5C47A4BA5@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "" Subject: Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)DHE public values be fresh X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 02 Jan 2017 18:52:21 -0000 On Mon, Jan 02, 2017 at 06:58:36PM +0200, Yoav Nir wrote: > > Still, if we want to accommodate the banking industry (or whatever > part of it we’ve talked to in Seoul), then they need to be able to > tell based on a timestamp which private key was used for that handshake. > With 60 seconds key changes are rare enough that there are at most two > possibilities which I think is manageable. With 10 seconds clock skew > can ruin your system. But I realize I’m bike shedding here. - If this is actually banking, they AFAIK do have accurate enough clocks (sub-second). - One can do seeded generation from ServerRandom. Adds load from use- once key generation, but avoids all time-skew problems. -Ilari From nobody Mon Jan 2 11:00:30 2017 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 C982D12943D for ; Mon, 2 Jan 2017 11:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 f1kOwHSFO9sR for ; Mon, 2 Jan 2017 11:00:27 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::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 ED3FA126BF7 for ; Mon, 2 Jan 2017 11:00:26 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id t125so272907565ywc.1 for ; Mon, 02 Jan 2017 11:00:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/LlmKPFfbJ09E0BaLmnC5t+rqCERsEBFoyyKabwFvPQ=; b=oY8ZFUBRTl2FV/c+TiCA04RMLQSkSV1yRlX8vCrfrqCUxDs9nOVW2kqfKFAvTUl3ui 7gzTA2POXpYDMF95m580o3M74ih4tGpzQqY0Wp4vI6y/g+WTLzUCBoKBoZIyPIdSv4el UNlHHTvtZ0NrTe/IgVF0s68aK+t9uNQSDcClafukNtQf5+FgiEdro66BeuGBk6/0ljVh FfjlWv5OGwReZak01mvXXEdNBd2m+dBSsnOdPEkQgXjV/WeANj81f2Hml+mTvGLkf3dG N0myyvlcthoPdkip8qWGQyvgW+MTrBM8hWookKxnk8GNFLtkXVKd+eLbh7oAyqGEWcCn QnNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/LlmKPFfbJ09E0BaLmnC5t+rqCERsEBFoyyKabwFvPQ=; b=IeUEiGmh2tu/CrjujUwKCn3Okph1ThKQFQZpTnSBsPGumqDObhCrkXSTKZYtGnWh0n PvNHCaZM7OAvUtOOl2FJUXL9lPMq62pRxMXfzK/tLjZzGzFHOi+gjIKG9JxVmc6B3124 s/TS9bGmFs7TFiD3HJZNa2ey65meO7rz6mD6iuXNLprVv9TXDUzeASBpRTAs7Oplm6H1 nr8Wo8S6/KkJruMs5uf57hiuBfspkHxzY3+6WHb/tfuOsnSGfumFxcIAtuK2Mm9JlJcT 3g+pAFTt8cQiMbWVp+1J5HpIZiaZJp+E4o1bQjgtwXhKRYkOCbbGXXPFb4Q0jQBikixh r1Bw== X-Gm-Message-State: AIkVDXIcoDxwXexQZW7PzCmbIup14XfF4B3HQ4COtp645Pn6tIXUUIQsXSPnSmgtfmSaaLQdEmWgrDq37gaFOw== X-Received: by 10.13.195.5 with SMTP id f5mr58774753ywd.354.1483383626174; Mon, 02 Jan 2017 11:00:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.164.210 with HTTP; Mon, 2 Jan 2017 10:59:45 -0800 (PST) In-Reply-To: <5542029D-293A-44F5-9A11-62F5C47A4BA5@gmail.com> References: <1483330131409.25713@cs.auckland.ac.nz> <5542029D-293A-44F5-9A11-62F5C47A4BA5@gmail.com> From: Eric Rescorla Date: Mon, 2 Jan 2017 10:59:45 -0800 Message-ID: To: Yoav Nir Content-Type: multipart/alternative; boundary=001a114d5fd61ab4e60545212a7a Archived-At: Cc: "" Subject: Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)DHE public values be fresh X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 02 Jan 2017 19:00:29 -0000 --001a114d5fd61ab4e60545212a7a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jan 2, 2017 at 8:58 AM, Yoav Nir wrote: > On 31 Dec 2016, at 20:36, Adam Langley wrote: > > Consider the motivations here: > > 1) We know that some implementations have gotten this wrong with TLS > 1.2 and cached values for far too long. Presumably if they were to be > naively extended to TLS 1.3 this issue would carry over. > > 2) We probably disagree with this banking industry desire to be able > to backdoor their TLS connections, but we're not the police and fixing > DH values is probably how they would do it. If it's going to be A > Thing then it's much more likely that things will get misconfigured > and it'll be enabled in places where it shouldn't be. If we have no > detection mechanism then what we'll probably end up with is a Blackhat > talk in a few years time about how x% of banks botched forward > security at their frontends. > > Say that a value of an hour makes sense for some device and we feel > that an hour's forward-security window is reasonable for security. The > issue is that it significantly diminishes our detection ability > because clients need to remember more than an hour's worth of values > and I don't know if we can dedicate that amount of storage to this. > > Since I think the utility of this falls off as a reciprocal, I'll try > making a concrete suggestion for a time limit: 10 seconds. > > > I like this number, because that=E2=80=99s the number I chose when I impl= emented > ECDH caching in Check Point=E2=80=99s TLS library. It makes key generatio= n rare > enough that it makes no difference for server load in any normal hardware= , > and frequent enough that if you destroy the keys after they are last used > then attackers have a very narrow window of opportunity to get your keys. > Especially if they need to get a warrant. IoT may be abnormal hardware in > that regard. > > Still, if we want to accommodate the banking industry (or whatever part o= f > it we=E2=80=99ve talked to in Seoul), then they need to be able to tell b= ased on a > timestamp which private key was used for that handshake. With 60 seconds > key changes are rare enough that there are at most two possibilities whic= h > I think is manageable. With 10 seconds clock skew can ruin your system. > But I realize I=E2=80=99m bike shedding here. > Yoav, Why do you need a precise clock here? If you're going to retrospectively decrypt, you are going to need a list of all the private keys, so why can't you just index that by the public key in the handshake? -Ekr On 2 Jan 2017, at 6:09, Peter Gutmann wrote: > > Hugo Krawczyk writes: > > there may be applications with legitimate reasons not to use FS. > > > It's not so much reasons not to use FS (well, there are some specialised > cases > where people want to do that as well), it's reasons to reuse (EC)DH value= s. > This isn't something that was ever mentioned in the spec, it's what > developers > have implemented themselves in order to deal with high-load conditions. > This > also means that no matter what the spec might say in the future, if you'v= e > got > a developer facing a situation where they need 480% of available CPU to > service requests then they're going to do things like cache (EC)DH, > regardless > of what the spec says. So making it a MUST NOT will end up as what > someone on > PKIX once described as "workgroup posturing". Better to include an > advisory > note on using it, > > > Well, it just so happens=E2=80=A6 > https://github.com/tlswg/tls13-spec/pull/768/files > > Yoav > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a114d5fd61ab4e60545212a7a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jan 2, 2017 at 8:58 AM, Yoav Nir <ynir.ietf@gmail.com&g= t; wrote:
On 31 Dec 2016, at 20:36, Adam Langley &l= t;agl@imperialv= iolet.org> wrote:

Cons= ider the motivations here:

1) We know that some implementations have= gotten this wrong with TLS
1.2 and cached values for far too long. Pres= umably if they were to be
naively extended to TLS 1.3 this issue would c= arry over.

2) We probably disagree with this banking industry desire= to be able
to backdoor their TLS connections, but we're not the pol= ice and fixing
DH values is probably how they would do it. If it's g= oing to be A
Thing then it's much more likely that things will get m= isconfigured
and it'll be enabled in places where it shouldn't b= e. If we have no
detection mechanism then what we'll probably end up= with is a Blackhat
talk in a few years time about how x% of banks botch= ed forward
security at their frontends.

Say that a value of an ho= ur makes sense for some device and we feel
that an hour's forward-se= curity window is reasonable for security. The
issue is that it significa= ntly diminishes our detection ability
because clients need to remember m= ore than an hour's worth of values
and I don't know if we can de= dicate that amount of storage to this.

Since I think the utility of = this falls off as a reciprocal, I'll try
making a concrete suggestio= n for a time limit: 10 seconds.

= I like this number, because that=E2=80=99s the number I chose when I implem= ented ECDH caching in Check Point=E2=80=99s TLS library. It makes key gener= ation rare enough that it makes no difference for server load in any normal= hardware, and frequent enough that if you destroy the keys after they are = last used then attackers have a very narrow window of opportunity to get yo= ur keys. Especially if they need to get a warrant. IoT may be abnormal hard= ware in that regard.

Still, if we want to accommod= ate the banking industry (or whatever part of it we=E2=80=99ve talked to in= Seoul), then they need to be able to tell based on a timestamp which priva= te key was used for that handshake. With 60 seconds key changes are rare en= ough that there are at most two possibilities which I think is manageable. = With 10 seconds clock skew can ruin your system.=C2=A0 But I realize I=E2= =80=99m bike shedding here.

Yoa= v,

Why do you need a precise clock here? If you= 9;re going to retrospectively decrypt, you
are going to need a li= st of all the private keys, so why can't you just index that by the
public key in the handshake?

-Ekr

On 2 Jan 2017, at 6:09, Peter Gutm= ann <pgut= 001@cs.auckland.ac.nz> wrote:

Hugo Krawczyk <hugo@ee.technion.ac.il> writes:

there may be applications with legitimate reasons not t= o use FS.

It's not so much reasons not to use FS (= well, there are some specialised cases
where people want to do that as w= ell), it's reasons to reuse (EC)DH values.
This isn't something = that was ever mentioned in the spec, it's what developers
have imple= mented themselves in order to deal with high-load conditions.=C2=A0 Thisalso means that no matter what the spec might say in the future, if you= 9;ve got
a developer facing a situation where they need 480% of availabl= e CPU to
service requests then they're going to do things like cache= (EC)DH, regardless
of what the spec says.=C2=A0 So making it a MUST NOT= will end up as what someone on
PKIX once described as "workgroup p= osturing".=C2=A0 Better to include an advisory
note on using it,

Well, it just so happens=E2=80= =A6

Yoav


________________________= _______________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--001a114d5fd61ab4e60545212a7a-- From nobody Mon Jan 2 11:43:48 2017 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 15DC81296E4 for ; Mon, 2 Jan 2017 11:43:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 D2LYblJThLi9 for ; Mon, 2 Jan 2017 11:43:46 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 3872A1296E3 for ; Mon, 2 Jan 2017 11:43:46 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id m1so49893898wme.0 for ; Mon, 02 Jan 2017 11:43:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Uho5tSASUlRBwB3bl4wi66ajqrPdr5djSHh1vJAI1O8=; b=nBUAZq2aL+QK4DhnMZDyBl7ttdVZ55n7DJuR9hK0P7anjlx/h8YSFr41JVkjZjpHnf WWHxkU1IEs6TkL4HMx1SA6XLf7FolfOK91YT2h93Gj0J+n2YisZEZ85W5Q/26d4FwUeo e8KhOWyoplzzhmv/fwVGTPYlclmlPu/WRcQ8LiibBj7Kwx8YzpjLNtMyziKxBV1m8pG1 w+noVbJJvr5hEHVnmRdegroW5faOUkTi/+rojkH9WNDfFYLhUpoZwnMLXcA/6jxb/G/k l41O7a6JAwQbkDmXnnySuuAV2N1X14Id93n5T948kFjKvPf9XiQ0MRA/O0ip81TkEU6E rOaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Uho5tSASUlRBwB3bl4wi66ajqrPdr5djSHh1vJAI1O8=; b=FvuHAImygY02M3iWX6QMFyZ2YfmajXxgRVAuI1+DYYkRwVz0nYR0XA8UJI4eQCE2kR amht9Veot/IN4c2HDmeJPrhaI+71Rkvme7DMCpGtWdoUW5FXoLH0thd8Qj0thdUqRH/R jFiRhzUxQFM2v0s33IOl5saq2ADHqq7prLibn1FY64ZK9ZcqN0M33d+jtbWHlq1rUhep 5qWQP+v5QmC05UxVx1lLgW/b7oh2KmqQma+fPyUKCfEucnqNGIqdkG6AgzVifF1rRiK0 MeNU3KCJSYSKtHd8ETh0tcTKOoscKf7H7FYq+K8ZQ4cqO55k0H6W2h/GJ+mk0m/lQpOP 4BoA== X-Gm-Message-State: AIkVDXK1KnwaVc6BUCKBR4Am4vG+XdxWSuac+4mRzDJs86LdSOjlYa7LgCE9PQRrKMkiEQ== X-Received: by 10.28.46.197 with SMTP id u188mr55807923wmu.61.1483386224701; Mon, 02 Jan 2017 11:43:44 -0800 (PST) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id w197sm85883887wmd.11.2017.01.02.11.43.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Jan 2017 11:43:44 -0800 (PST) From: Yoav Nir Message-Id: <071A0098-8E03-4DCB-AA3F-4AD9424C9493@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_322260F7-545B-4840-A634-EA06EB47DA12" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 2 Jan 2017 21:43:41 +0200 In-Reply-To: To: Eric Rescorla References: <1483330131409.25713@cs.auckland.ac.nz> <5542029D-293A-44F5-9A11-62F5C47A4BA5@gmail.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "" Subject: Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)DHE public values be fresh X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 02 Jan 2017 19:43:48 -0000 --Apple-Mail=_322260F7-545B-4840-A634-EA06EB47DA12 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 2 Jan 2017, at 20:59, Eric Rescorla wrote: >=20 >=20 >=20 > On Mon, Jan 2, 2017 at 8:58 AM, Yoav Nir > wrote: >>=20 >> . >>=20 >> Since I think the utility of this falls off as a reciprocal, I'll try >> making a concrete suggestion for a time limit: 10 seconds. >=20 > I like this number, because that=E2=80=99s the number I chose when I = implemented ECDH caching in Check Point=E2=80=99s TLS library. It makes = key generation rare enough that it makes no difference for server load = in any normal hardware, and frequent enough that if you destroy the keys = after they are last used then attackers have a very narrow window of = opportunity to get your keys. Especially if they need to get a warrant. = IoT may be abnormal hardware in that regard. >=20 > Still, if we want to accommodate the banking industry (or whatever = part of it we=E2=80=99ve talked to in Seoul), then they need to be able = to tell based on a timestamp which private key was used for that = handshake. With 60 seconds key changes are rare enough that there are at = most two possibilities which I think is manageable. With 10 seconds = clock skew can ruin your system. But I realize I=E2=80=99m bike = shedding here. >=20 > Yoav, >=20 > Why do you need a precise clock here? If you're going to = retrospectively decrypt, you > are going to need a list of all the private keys, so why can't you = just index that by the > public key in the handshake? I=E2=80=99m assuming that the server generates private keys and saves = them to a file along with the time period that they were used, and = another machine in a different part of the network records traffic. = It=E2=80=99s not so much that the clocks need to be accurate, as that = they need to be synchronized, and there will still be some misalignment = because of (variable) latency.=20 I guess we are making guesses about systems that haven=E2=80=99t been = written yet. Yoav --Apple-Mail=_322260F7-545B-4840-A634-EA06EB47DA12 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 2 Jan 2017, at 20:59, Eric Rescorla <ekr@rtfm.com> = wrote:



On = Mon, Jan 2, 2017 at 8:58 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:

.

Since I think the utility of this falls off as a reciprocal, = I'll try
making a concrete suggestion for a time limit: 10 = seconds.

I like this number, because = that=E2=80=99s the number I chose when I implemented ECDH caching in = Check Point=E2=80=99s TLS library. It makes key generation rare enough = that it makes no difference for server load in any normal hardware, and = frequent enough that if you destroy the keys after they are last used = then attackers have a very narrow window of opportunity to get your = keys. Especially if they need to get a warrant. IoT may be abnormal = hardware in that regard.

Still, if we want to accommodate the banking industry (or = whatever part of it we=E2=80=99ve talked to in Seoul), then they need to = be able to tell based on a timestamp which private key was used for that = handshake. With 60 seconds key changes are rare enough that there are at = most two possibilities which I think is manageable. With 10 seconds = clock skew can ruin your system.  But I realize I=E2=80=99m bike = shedding here.

Yoav,

Why do you need a precise clock here? = If you're going to retrospectively decrypt, you
are = going to need a list of all the private keys, so why can't you just = index that by the
public key in the = handshake?

I=E2=80= =99m assuming that the server generates private keys and saves them to a = file along with the time period that they were used, and another machine = in a different part of the network records traffic. It=E2=80=99s not so = much that the clocks need to be accurate, as that they need to be = synchronized, and there will still be some misalignment because of = (variable) latency. 

I guess we = are making guesses about systems that haven=E2=80=99t been written = yet.

Yoav

= --Apple-Mail=_322260F7-545B-4840-A634-EA06EB47DA12-- From nobody Mon Jan 2 12:05:41 2017 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 0226F12970F for ; Mon, 2 Jan 2017 12:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.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 bY8aKXjatrfc for ; Mon, 2 Jan 2017 12:05:38 -0800 (PST) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::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 97E3E1296EA for ; Mon, 2 Jan 2017 12:05:38 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id a10so274105709ywa.3 for ; Mon, 02 Jan 2017 12:05:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZgpS8X515wW5qtWblkvUJeqiTu6ErQ9DeojvNJZgTIE=; b=rKMlmIHEloYsMS2Z4e+qTIRfxmiJRKeJLuCs30lOxSq+UUV6ZnbjZMTrt3wvjoqqnM A7LFiyaIBulKCAGVo3TBbSrms++QgFY9liR+1WQxqU4Z4NJJi2v8f4odS8d6gm8Q3fKd sF7M+MILPMBXPlyjSyB3vcbvHHnn4r0h7th254JFeKZpw//w9slZqhnWXkj7KdOWgnJX BQpkYW7AE5XZJxbp6+k/4uOWe+P1ob1bbuKBJh5Ff9REW5WvHzH/+xkaBzUOEkrS3bIj GRFynvf/PVguhBakRKGJZQlVX5Ng6KBje237L/ev/Y9Pzz4K67HBq+UX/Zb3+bJElHkQ 5rpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZgpS8X515wW5qtWblkvUJeqiTu6ErQ9DeojvNJZgTIE=; b=FusFMtG/p1rGdqRjy4Wcph7zuBNd8dEo8fw3uqbdxhAK7M+rrROUx4/YaFp9Llppq4 S3NfQ+SSr6gjw1HKsPCoS+CfCkIpo0Ke1wUp9TA5Tvy3JdtkreYsQs2lSvFk9Js+Dn7F 1MyfiQxKgPbDJCI9CyOrNxPHjDcNZIFPpYGXGJRXPd8spbxjlNMXluumBJcTIg5o+7QR vkXS2IAT0ZJlW3eUxAfRWJLVI2HNU5kKQPvS3OVMsWmwD9hXe/8JEttTEIx249TBnU3v uVJ3xY0qg9fKthxYemhqIuvQmty5Dt61f9C8kdXahNr0ugUZOmVwtnPbAhJlVuvLeWwD LLcw== X-Gm-Message-State: AIkVDXJyH4yeoA2nxP4kp0du4B2qCZZH28EzfbUS2LELuqvN+8LpQDBZSpngMVelGZF0hyg6iJloxenKE3UmFg== X-Received: by 10.13.225.151 with SMTP id k145mr52806874ywe.121.1483387537873; Mon, 02 Jan 2017 12:05:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.161.73 with HTTP; Mon, 2 Jan 2017 12:05:37 -0800 (PST) In-Reply-To: <071A0098-8E03-4DCB-AA3F-4AD9424C9493@gmail.com> References: <1483330131409.25713@cs.auckland.ac.nz> <5542029D-293A-44F5-9A11-62F5C47A4BA5@gmail.com> <071A0098-8E03-4DCB-AA3F-4AD9424C9493@gmail.com> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Mon, 2 Jan 2017 12:05:37 -0800 Message-ID: To: Yoav Nir Content-Type: multipart/alternative; boundary=94eb2c075ed0428ff7054522134f Archived-At: Cc: "" Subject: Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)DHE public values be fresh X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 02 Jan 2017 20:05:40 -0000 --94eb2c075ed0428ff7054522134f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jan 2, 2017 at 11:43 AM, Yoav Nir wrote: > I=E2=80=99m assuming that the server generates private keys and saves the= m to a > file along with the time period that they were used, and another machine = in > a different part of the network records traffic. It=E2=80=99s not so much= that the > clocks need to be accurate, as that they need to be synchronized, and the= re > will still be some misalignment because of (variable) latency. > > I guess we are making guesses about systems that haven=E2=80=99t been wri= tten yet. > Logging the actual session keys is a feature that some Enterprise appliances have today, and that would continue to work in all scenarios (sadly). It's not that much data to log (far less than a request log for example). In that case it's often left unindexed and simple tools like grep are used for ad-hoc decryption requests,which are typically rare enough not to merit anything better. For simplicities sake, I'd prefer single-use ECDHE, rather than time-delimited. Mostly because it's simpler to implement. The current generation of IOT and other small embedded systems are already at the point where they can do this kind of thing. --=20 Colm --94eb2c075ed0428ff7054522134f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jan 2, 2017 at 11:43 AM, Yoav Nir <ynir.ietf@gm= ail.com> wrote:
=
I=E2=80=99m assuming that the server generates private keys and saves = them to a file along with the time period that they were used, and another = machine in a different part of the network records traffic. It=E2=80=99s no= t so much that the clocks need to be accurate, as that they need to be sync= hronized, and there will still be some misalignment because of (variable) l= atency.=C2=A0

I guess we are making guesses about = systems that haven=E2=80=99t been written yet.

Logging the actual session keys is a feature that some Ente= rprise appliances have today, and that would continue to work in all scenar= ios (sadly). It's not that much data to log (far less than a request lo= g for example). In that case it's often left unindexed and simple tools= like grep are used for ad-hoc decryption requests,which are typically rare= enough not to merit anything better.=C2=A0

For si= mplicities sake, I'd prefer single-use ECDHE, rather than time-delimite= d. Mostly because it's simpler to implement. The current generation of = IOT and other small embedded systems are already at the point where they ca= n do this kind of thing.=C2=A0

--
Colm
--94eb2c075ed0428ff7054522134f-- From nobody Mon Jan 2 12:57:09 2017 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 0BF051295D4 for ; Mon, 2 Jan 2017 12:57:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 HY2a70dVN2i7 for ; Mon, 2 Jan 2017 12:57:06 -0800 (PST) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 7A6DB129443 for ; Mon, 2 Jan 2017 12:57:06 -0800 (PST) Received: by mail-io0-x232.google.com with SMTP id h133so181531565ioe.3 for ; Mon, 02 Jan 2017 12:57:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=j2HkM2dX5RfS84XXwpdarXf8hgY8bxw3xrVzSTQIKnU=; b=U33L8RuLRIdtt+BukVaJgMudlhhc9adMHsVQBTHKFNLhGJeMKJQxo+HGj1gKKo7dpJ 5R5fJmv7j3CFbsPYfYNF1A4Lf3LvuXuDvtSnWhXhQ+BLS1QIQvzYzD5NcWrKPiRlS2dy JKvdScPKCO3/QLGnItFzD3h1ud37beDVJrqv0tGI3aZJY0tuF+mWSjUdVnbBHwCPLAVB op7TaUFsuzCpaQwkKNY2iIj+cPG0fIkM7Tow/MXo9NYrXJeahwUp6Xzfro9vKSuF8I51 NrAQqCoMCxTMwK+xMYojDMPDTmSV9m+VA+/kQOreCWcgNdSh+ncH/f5lUyQCHmf3Ecyf GOSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=j2HkM2dX5RfS84XXwpdarXf8hgY8bxw3xrVzSTQIKnU=; b=Xek9ySIj1ysSsVIfv7tQ58QToFe0SR60DZJCcbLhzlk6qPVX4zuzECz/EbPZIW3p4g PQcJKp9zMLg5nRTpedKHVBdeKQRlI8HSDeqyakcuiQWpIeYN1uRN1OOwLgYp+ni0INtV wbzbpVL57/Eu3EV5lROD9QgOaFV4zpbeYscj6GZ51n7k0G8NghyOq2SCUDrG1JYdVQJ8 UhJJe0lWRnII8md/J956GprV9a7kA+DGnzCqiK2yw2M9THi+7fC/hfPFIDckH98fCfNQ p+8dcawqunR4ziXH4gyAbH11+qMk6YHQZzcmBPbgpQnLIqtgKSxnSqosy7A4wtb0FIzj TvvA== X-Gm-Message-State: AIkVDXJAyofjQnDqYL9ufdNfrKsOGEgiGbj9cNtUe+j0CONL8FfozzfTIDVc9AhG7wYJaw4gzDBmeiSFxk5SlA== X-Received: by 10.107.154.206 with SMTP id c197mr47513947ioe.97.1483390625735; Mon, 02 Jan 2017 12:57:05 -0800 (PST) MIME-Version: 1.0 Sender: alangley@gmail.com Received: by 10.36.27.136 with HTTP; Mon, 2 Jan 2017 12:57:05 -0800 (PST) In-Reply-To: <071A0098-8E03-4DCB-AA3F-4AD9424C9493@gmail.com> References: <1483330131409.25713@cs.auckland.ac.nz> <5542029D-293A-44F5-9A11-62F5C47A4BA5@gmail.com> <071A0098-8E03-4DCB-AA3F-4AD9424C9493@gmail.com> From: Adam Langley Date: Mon, 2 Jan 2017 12:57:05 -0800 X-Google-Sender-Auth: rEI9jtYQcdqzscOmOmUBAAyz8j8 Message-ID: To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "" Subject: Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)DHE public values be fresh X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 02 Jan 2017 20:57:08 -0000 On Mon, Jan 2, 2017 at 11:43 AM, Yoav Nir wrote: > I=E2=80=99m assuming that the server generates private keys and saves the= m to a file > along with the time period that they were used, and another machine in a > different part of the network records traffic. It=E2=80=99s not so much t= hat the > clocks need to be accurate, as that they need to be synchronized, and the= re > will still be some misalignment because of (variable) latency. > > I guess we are making guesses about systems that haven=E2=80=99t been wri= tten yet. Addressing a few messages in one: I didn't intend that this MUST NOT just be a "MUST NOT (but we know you will)". I agree they're pretty useless. Rather I want this to be checked in some clients and in tools like SSLLabs. I have some faith that such measures will work to push an ecosystem towards correctness. I don't expect that those who want to intercept TLS connections will see a MUST NOT and go do something else. Rather I think they should understand that TLS isn't supposed to be intercepted and, if they want to do that, then they're going to be breaking the spec in places. I think they're going to do that no matter what we do so I want to ensure that these "interceptable" implementations don't inadvertently proliferate. (Because if everything Just Works when you accidentally copy such a config to your frontend server, then it'll happen.) Cheers AGL From nobody Tue Jan 3 05:59:31 2017 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 A41F812944C for ; Tue, 3 Jan 2017 05:59:30 -0800 (PST) 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 (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 uh-ZbLUVEG2W for ; Tue, 3 Jan 2017 05:59:29 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 44F15129411 for ; Tue, 3 Jan 2017 05:59:29 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id c47so462912055qtc.2 for ; Tue, 03 Jan 2017 05:59:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=XrA/v1lYYP8YLFLg4OUjDjQplm1jpkHAXm0i8AY6Z6Q=; b=DerMGB99+NtawSCKAOxbhHse14/xHX2DPFRej+pn8y/WYmB76gKRy1EiNl0i/OLJZh 1KRuikEfcQMGrsZUL7R/T1yyCiAt9KldS32ZSn5jYx4MlGl757zHQvFFcQxUvpKoSuPm LTIP6cNk9dNWvvwGmRFZCsDUy3gZrikBWKoIU= 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:subject :message-id:date:to:mime-version; bh=XrA/v1lYYP8YLFLg4OUjDjQplm1jpkHAXm0i8AY6Z6Q=; b=hYhBmReQcXV346VbQ5MkbDHTlXXrMHWBjtJyrx260S5pIjl7sB6NupGRj0s9IPhNQB DWR1JlBll3B6H8pq6GC1qEsDG2Pv+k7ereyyOcrNFWOlmJ0oHSICUcrNH5ESBlzNrZgy 6uUz5IzR50jg/0IimdXUA6i9ppPUdUp3WxoBonCBacZhdJkibyH3OZjPU1/qiLqnqepC NcbXSpI8Vj1whJyfDPU3XIrsV392Mtm6O5dSFU66g4iaEqRcZKv956AzEN3G2R7wQAk4 hMSMGQAi/dzvBnx8YTFI06mEMYowARrGdPoYGrkPPAp0soeA1LNvhBx/suVZSZD2xCmu 2HNw== X-Gm-Message-State: AIkVDXLSAP/dRs200mRvlZUD0YF1BVqCgyjE6WP6b47tX2BwYIdgJuCv/6OKDdDJ71g5BA== X-Received: by 10.237.41.2 with SMTP id s2mr53293305qtd.89.1483451967841; Tue, 03 Jan 2017 05:59:27 -0800 (PST) Received: from [172.16.0.92] (pool-173-73-120-80.washdc.east.verizon.net. [173.73.120.80]) by smtp.gmail.com with ESMTPSA id m30sm43497451qta.7.2017.01.03.05.59.26 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 03 Jan 2017 05:59:26 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 3 Jan 2017 08:59:25 -0500 To: "" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [TLS] adopted: draft-thomson-tls-tls13-vectors X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 03 Jan 2017 13:59:30 -0000 I appears that we=E2=80=99ve got enough consensus/interest to adopt = draft-thomson-tls-tls13-vectors based on this thread: https://mailarchive.ietf.org/arch/msg/tls/LOS06OPDeLOrdtE8QoBLXEHO51s Martin, Please submit draft-ietf-tls-tls13-vectors at your earliest convenience. = I=E2=80=99ll set up a tlswg repo in just a sec. Thanks!=20 J&S= From nobody Tue Jan 3 05:59:41 2017 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 7F9E31295EE for ; Tue, 3 Jan 2017 05:59:39 -0800 (PST) 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 (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 PWg-mkyO7OKI for ; Tue, 3 Jan 2017 05:59:36 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 9A5041295E1 for ; Tue, 3 Jan 2017 05:59:36 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id h201so235945667qke.1 for ; Tue, 03 Jan 2017 05:59:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=pHrp3LaFpVI7ztu/Hd0Ad9iC6+PJIKwDqH5rQKUj4CY=; b=emzMrHxtRPpt8hkGfZpXUNaEuteWvuLN9TGrOLBICVrsYORXr7RhiyAtMtlY4dZdgQ qNf6m9WPMATtBDtd/iIH64U1DvCSD29qnwe5+iu8KcAe5/Reud5WEtVk91ASn+RT7EB3 asxP7R/zSw2lQwFKgnTpRHK9vqa82L2vjTABo= 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:subject :message-id:date:to:mime-version; bh=pHrp3LaFpVI7ztu/Hd0Ad9iC6+PJIKwDqH5rQKUj4CY=; b=iqkH4krzjWXdpbXBNlTgIQgMytT/oSBoYwNcP8QEB4SoynA6HShrvCwWIhubbmwUVP QY8wtzUNAzwn+huf3tX1DS/13dQ+2E0xxjosdAXV0ZYklKjtEVUYB5yUSmgNkcMRXMp9 J15XuopPFEP2FmjWnvzryv0jv9/f0pNrU8O4NSiZsFiIAf4HTnrDuFksd6KTdV5ZK9so DwE6zOzSIOwLgIg2Ke4WMQldNhcrV4pnwRNtrRTb31BbSOfTaNXFALlSzK+/2NNR9jgo kpuhK1Re+dVLunEpUVwYIsECj5G6PDzgOlvhGCreMYwNYyXo+OwoP7U7Iox7xiRA+LJp F5OQ== X-Gm-Message-State: AIkVDXJTiEogmz1p1G3RXoBiR1BXOv2ei8A2rt6hO9B+08Iv7J8pjL5qiATCYtQWTRY5fA== X-Received: by 10.55.9.15 with SMTP id 15mr60535364qkj.118.1483451975413; Tue, 03 Jan 2017 05:59:35 -0800 (PST) Received: from [172.16.0.92] (pool-173-73-120-80.washdc.east.verizon.net. [173.73.120.80]) by smtp.gmail.com with ESMTPSA id m30sm43497451qta.7.2017.01.03.05.59.34 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 03 Jan 2017 05:59:34 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <4C288CF8-28D4-4E03-914C-08D238C84292@sn3rd.com> Date: Tue, 3 Jan 2017 08:59:33 -0500 To: "" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [TLS] adopted: draft-davidben-tls-grease X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 03 Jan 2017 13:59:39 -0000 I appears that we=E2=80=99ve got enough consensus/interest to adopt = draft-davidben-tls-grease based on this thread: https://mailarchive.ietf.org/arch/msg/tls/NnNMMRygtXzPXMg3d6WlSBrsZ7w David, Please submit draft-ietf-tls-grease at your earliest convenience. = I=E2=80=99ll set up a tlswg repo in just a sec. Thanks!=20 J&S= From nobody Tue Jan 3 16:14:28 2017 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 1E23E1294ED for ; Tue, 3 Jan 2017 16:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 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_LOW=-0.7, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 s2RfztsAOzW2 for ; Tue, 3 Jan 2017 16:14:25 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0861294FA for ; Tue, 3 Jan 2017 16:14:25 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 7B9CA433433; Wed, 4 Jan 2017 00:14:24 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 5B05E433431; Wed, 4 Jan 2017 00:14:24 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1483488864; bh=A3i5bkbex8L1hLCHorz2BkSXzWK6XqQCMf1tZQ7dd84=; l=3741; h=To:References:Cc:From:Date:In-Reply-To:From; b=lFsLOdW3aqenlov5PasRetqxUhfZFouqqxzmfm1+XQ+WT70TfGWuho3McctvZK6Qd GVglIoTcuOjZ/LGhg9w22NGxd2OkyvwhuZ9P7QPB9h9blNxkp3nhM1TqCoHRJ4yIu+ lRwN8ZhxttgOqEDhmcUqUFKEGbOz7lPRfVEHe2YQ= Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 1A5E61FC88; Wed, 4 Jan 2017 00:14:24 +0000 (GMT) To: Ilari Liusvaara , Adam Langley References: <79db4a88-e435-2e5b-47a5-9048acef45e2@cs.tcd.ie> <582703ab-4340-35e7-a3d2-45dd606f10a1@cs.tcd.ie> <20161230124420.GA11229@LK-Perkele-V2.elisa-laajakaista.fi> From: Benjamin Kaduk Message-ID: <5e06f30a-2f29-0c1f-432b-ed02c7f6c5ae@akamai.com> Date: Tue, 3 Jan 2017 18:14:23 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20161230124420.GA11229@LK-Perkele-V2.elisa-laajakaista.fi> Content-Type: multipart/alternative; boundary="------------36D410612ACEC6681271E492" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] cross-domain cache sharing and 0rtt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 04 Jan 2017 00:14:27 -0000 This is a multi-part message in MIME format. --------------36D410612ACEC6681271E492 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 12/30/2016 06:44 AM, Ilari Liusvaara wrote: > On Thu, Dec 29, 2016 at 02:45:53PM -0800, Adam Langley wrote: >> >> An attacker could redirect a 0-RTT handshake that was destined to S1 >> and feed it to S2. If S2 ignores the SNI value (common) it could >> accept and process the 0-RTT data even though it was destined for S1. > Sounds like standard-issue default-vhost attack (which are sadly > common security issues in https://). > Somehow, I feel like adding text in the 1.3 spec that servers should not do this is not really going to help anyone. >> However, in that case TLS 1.2 is probably also affected because S2 >> would likely process a 1.2 handshake that was destined to S1 as well. >> (Even without a shared ticket key or session cache.) See >> http://antoine.delignat-lavaud.fr/doc/www15.pdf for more. > You mean redirecting full handshake meant for s1.example.com to > s2.example.com? Or redirecting a TLS 1.2 resumption handshake? Naively, if s1 and s2 share cert and private key, and ignore the SNI, it seems like redirecting a full handshake would work. But I didn't think about it very hard. > Also, wonder how many servers don't check for SNI when resuming... > Me, too. -Ben --------------36D410612ACEC6681271E492 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 12/30/2016 06:44 AM, Ilari Liusvaara wrote:
On Thu, Dec 29, 2016 at 02:45:53PM -0800, Adam Langley wrote:


An attacker could redirect a 0-RTT handshake that was destined to S1
and feed it to S2. If S2 ignores the SNI value (common) it could
accept and process the 0-RTT data even though it was destined for S1.

Sounds like standard-issue default-vhost attack (which are sadly
common security issues in https://).

Somehow, I feel like adding text in the 1.3 spec that servers should not do this is not really going to help anyone.


      

        
However, in that case TLS 1.2 is probably also affected because S2
would likely process a 1.2 handshake that was destined to S1 as well.
(Even without a shared ticket key or session cache.) See
http://antoine.delignat-lavaud.fr/doc/www15.pdf for more.


      

      
You mean redirecting full handshake meant for s1.example.com to
s2.example.com? Or redirecting a TLS 1.2 resumption handshake?


    

    

    Naively, if s1 and s2 share cert and private key, and ignore the
    SNI, it seems like redirecting a full handshake would work. But I
    didn't think about it very hard.

    

    

      
Also, wonder how many servers don't check for SNI when resuming...



    

    

    

    Me, too.

    

    -Ben

  


--------------36D410612ACEC6681271E492--


From nobody Tue Jan  3 17:02:44 2017
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 92F0B12946F for ; Tue,  3 Jan 2017 17:02:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.811
X-Spam-Level: 
X-Spam-Status: No, score=-3.811 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 ZaK639NjhWjq for ; Tue,  3 Jan 2017 17:02:40 -0800 (PST)
Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 38C60129408 for ; Tue,  3 Jan 2017 17:02:40 -0800 (PST)
Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 9550C433435; Wed,  4 Jan 2017 01:02:39 +0000 (GMT)
Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 7F397433414; Wed,  4 Jan 2017 01:02:39 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1483491759; bh=+F6om8/si7m2N3nMr8UO5pX6C6mfjjiMeSCuxBLpOQ4=; l=13377; h=To:References:Cc:From:Date:In-Reply-To:From; b=LPnP0N5DPo41XrngskTvFIy42ce1q+mDDimVbXru/Hvcq0sqX49JUzdW6f+FM+CtX lZDy/JXoLaNmF8Z6c/Rtd1LuQ8yKK3nKM7NiFcB7P+ApmrqnNvsVK6j1fzwr2TnTN/ CSXZynYXNXvRCBp/6hLE7tV8SBluALthftelNOdM=
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 37C7F1FC86; Wed,  4 Jan 2017 01:02:39 +0000 (GMT)
To: Russ Housley , David Benjamin 
References: <0DA64421-5975-4B7E-BC08-7428AFA9D1A1@vigilsec.com>  <9D8BEE12-49F9-4DE3-81C7-909CB114805F@vigilsec.com>
From: Benjamin Kaduk 
Message-ID: <1b678d65-b146-b25f-c1ad-6dfc044f7ce0@akamai.com>
Date: Tue, 3 Jan 2017 19:02:38 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <9D8BEE12-49F9-4DE3-81C7-909CB114805F@vigilsec.com>
Content-Type: multipart/alternative; boundary="------------098FE66D94B8C819616ADC7C"
Archived-At: 
Cc: IETF TLS 
Subject: Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 04 Jan 2017 01:02:42 -0000

This is a multi-part message in MIME format.
--------------098FE66D94B8C819616ADC7C
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit

I also had the sense that ekr noted that we didn't want to do this in
the core spec.
So, could you point me more clearly at what you would want to change in
the core spec that would allow doing the thing you want to see done in a
future document?  (Is it just removing "i.e., when a PSK is not in use"?)

-Ben

On 12/22/2016 04:29 PM, Russ Housley wrote:
> David:
>
> Yes, it does allow both, but the authentication is unclear when both
> are in play. The last bullet implies that certificate authentication
> only comes into play when there is no PSK.  So, if there is a PSK, the
> identity associated with it seems to trump whatever is in the certificate.
>
> As I explained below, Id like the identity associate with the
> External PSK and the identity in the certificate to both have a role.
>
> Russ
>
>
> On Dec 22, 2016, at 5:12 PM, David Benjamin  > wrote:
>
>> It's possible I'm misunderstanding your message here (I'm a little
>> confused by the mention of combining normal certificate
>> authentication with an external PSK), but TLS 1.3 already allows
>> doing both PSK and (EC)DH. That's the psk_dhe_ke mode, rather than
>> the psk_ke mode. It's signaled by the server by sending both
>> pre_shared_key and key_share extensions. Perhaps the wording should
>> be a bit clearer.
>>
>> Our stack does not even implement psk_ke. It always requires an
>> (EC)DH operation in a TLS 1.3 handshake, whether using PSK or
>> certificates.
>>
>> David
>>
>> On Thu, Dec 22, 2016 at 4:54 PM Russ Housley > > wrote:
>>
>>     I want to make sure that it is possible to mix PSK with (EC)DH as
>>     a protection against the discovery of a quantum computer.  I
>>     recognize that the WG does not want to tackle this topic in the
>>     base specification; however, the following text in Section 4.1.1
>>     makes this difficult to do so in a companion document:
>>
>>     >    The server indicates its selected parameters in the
>>     ServerHello as
>>     >    follows:
>>     >
>>     >    -  If PSK is being used then the server will send a
>>     "pre_shared_key"
>>     >       extension indicating the selected key.
>>     >
>>     >    -  If PSK is not being used, then (EC)DHE and certificate-based
>>     >       authentication are always used.
>>     >
>>     >    -  When (EC)DHE is in use, the server will also provide a
>>     "key_share"
>>     >       extension.
>>     >
>>     >    -  When authenticating via a certificate (i.e., when a PSK
>>     is not in
>>     >       use), the server will send the Certificate (Section
>>     4.4.1) and
>>     >       CertificateVerify (Section 4.4.2) messages.
>>
>>     An Internal PSK offers no protection against the discovery of a
>>     quantum computer.  I assume that an attacker can save the
>>     handshake that established the Internal PSK, and then at some
>>     future date use the quantum computer to discover the Internal
>>     PSK.  Therefore, protection against the discovery of a quantum
>>     computer is only concerned with External PSK.
>>
>>     I would like for the specification to permit normal certificate
>>     authentication when someone is using an External PSK.  I am
>>     guessing that the granularity of the name associated with the
>>     External PSK to be pretty broad.  If this guess is correct, it
>>     would be appropriate for the name in the certificate to be
>>     further restrict the one associated with the External PSK.  Maybe
>>     the External PSK is associated with example.com
>>     ,
>>     and then the certificate that includes www.example.com
>>     
>>     would be acceptable acceptable.  Then, I would expect any
>>     Internal PSK that is generated after such an authentication would
>>     be associated with the more granular certificate name.
>>
>>     Maybe it is as simple as reorganizing these bullets like this:
>>
>>        - When only PSK is being used, 
>>
>>        - When only (EC)DHE is being used, 
>>
>>        - When PSK and (EC)DHE are both being used, 
>>
>>     If others agree with this direction, I am willing to propose some
>>     text.
>>
>>     Happy holidays,
>>        Russ
>>     _______________________________________________
>>     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


--------------098FE66D94B8C819616ADC7C
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    I also had the sense that ekr noted that we didn't want to do
      this in the core spec.

      So, could you point me more clearly at what you would want to
      change in the core spec that would allow doing the thing you want
      to see done in a future document? (Is it just removing "i.e.,
      when a PSK is not in use"?)

      

      -Ben

    

    
On 12/22/2016 04:29 PM, Russ Housley
      wrote:

    

    

      
      David:
      


      

      
Yes, it does allow both, but the authentication is unclear
        when both are in play. The last bullet implies that certificate
        authentication only comes into play when there is no PSK. So,
        if there is a PSK, the identity associated with it seems to
        trump whatever is in the certificate.

      


      

      
As I explained below, Id like the identity associate with
        the External PSK and the identity in the certificate to both
        have a role.

      


      

      
Russ

      


      

      


      

      
On Dec 22, 2016, at 5:12 PM, David Benjamin <davidben@chromium.org>
        wrote:
        


          

            
It's possible I'm misunderstanding your
              message here (I'm a little confused by the mention of
              combining normal certificate authentication with an
              external PSK), but TLS 1.3 already allows doing both PSK
              and (EC)DH. That's the psk_dhe_ke mode, rather than the
              psk_ke mode. It's signaled by the server by sending both
              pre_shared_key and key_share extensions. Perhaps the
              wording should be a bit clearer.
              


              

              
Our stack does not even implement psk_ke. Italways
                requires an (EC)DH operation in a TLS 1.3 handshake,
                whether using PSK or certificates.

              

                


                

                
David

                  

                  

                    
On Thu, Dec 22, 2016 at 4:54 PM Russ
                      Housley <housley@vigilsec.com>
                      wrote:

                    

                    
I want to make
                      sure that it is possible to mix PSK with (EC)DH as
                      a protection against the discovery of a quantum
                      computer. I recognize that the WG does not want
                      to tackle this topic in the base specification;
                      however, the following text in Section 4.1.1 makes
                      this difficult to do so in a companion document:

                      

                      >  The server indicates its selected
                      parameters in the ServerHello as

                      >  follows:

                      >

                      >  - If PSK is being used then the server
                      will send a "pre_shared_key"

                      >   extension indicating the selected key.

                      >

                      >  - If PSK is not being used, then (EC)DHE
                      and certificate-based

                      >   authentication are always used.

                      >

                      >  - When (EC)DHE is in use, the server will
                      also provide a "key_share"

                      >   extension.

                      >

                      >  - When authenticating via a certificate
                      (i.e., when a PSK is not in

                      >   use), the server will send the
                      Certificate (Section 4.4.1) and

                      >   CertificateVerify (Section 4.4.2)
                      messages.

                      

                      An Internal PSK offers no protection against the
                      discovery of a quantum computer. I assume that an
                      attacker can save the handshake that established
                      the Internal PSK, and then at some future date use
                      the quantum computer to discover the Internal
                      PSK. Therefore, protection against the discovery
                      of a quantum computer is only concerned with
                      External PSK.

                      

                      I would like for the specification to permit
                      normal certificate authentication when someone is
                      using an External PSK. I am guessing that the
                      granularity of the name associated with the
                      External PSK to be pretty broad. If this guess is
                      correct, it would be appropriate for the name in
                      the certificate to be further restrict the one
                      associated with the External PSK. Maybe the
                      External PSK is associated with example.com, and then the
                      certificate that includes www.example.com would be
                      acceptable acceptable. Then, I would expect any
                      Internal PSK that is generated after such an
                      authentication would be associated with the more
                      granular certificate name.

                      

                      Maybe it is as simple as reorganizing these
                      bullets like this:

                      

                       - When only PSK is being used, 

                      

                       - When only (EC)DHE is being used, 

                      

                       - When PSK and (EC)DHE are both being used, 

                      

                      If others agree with this direction, I am willing
                      to propose some text.

                      

                      Happy holidays,

                       Russ

                      _______________________________________________

                      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


    

    

  


--------------098FE66D94B8C819616ADC7C--


From nobody Tue Jan  3 18:36:47 2017
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 2747512997F for ; Tue,  3 Jan 2017 18:36:45 -0800 (PST)
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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 nJL8gaXnsy38 for ; Tue,  3 Jan 2017 18:36:44 -0800 (PST)
Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 DE12412944F for ; Tue,  3 Jan 2017 18:36:43 -0800 (PST)
Received: by mail-qt0-x233.google.com with SMTP id c47so479843520qtc.2 for ; Tue, 03 Jan 2017 18:36:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=J1eA/WHkzbxtsauWi3Nun3eH3qf3/mRUADER7eU0BQY=; b=Eh+aGaoNVaRS4W16IzBIhESl20M+zeMGyymJfjNUWUNUiqtH2UhLADLAFHfB794USg WJyg63gKHdLSYgVRwb8LHL0veTA4VYz6+xBNBvxR5otziSK45VP6VyCV5H9vAeetb875 TKtbhihRMOBZqfvvXSjoVJLI6cciIKU4BgE0+fRBKAiBIcq2QrPlFtQce5DuZx1ZOeQY +prCcZK68zN+OWh9kCdM+R/xzv6RRBAm6YwrmDswiWMNlPqU6crdoY2An1dyIo5NJwnq bIAm1lcDbYoiuICzedPz7KJBBZMsTBS9d4uOSfrEUsp7hrVEgX9XEw5bNg2SZ6mSAPKF rQvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=J1eA/WHkzbxtsauWi3Nun3eH3qf3/mRUADER7eU0BQY=; b=lBTvu8Yx0TU4N1H9iePGFNoSEzYoG6Y8Rj9F8pTLK62FfOOoQIV4XbP81vCnW80Gdd IUIplCb+T6o2ZgWRiT6cxAF8PDxsyS9UprJC4nzCZY5+I3u07vTjRB2WuOLtUl0hJT9r kGYnWxDLms0Cwu+zkhVqUZCgXWrVouw++lu9FUoHVFJtz+ayhYUa4InmvJ8EQGXfjBLi snYD4Ozjs4MyQnWSWRXw1VyWKEJOtHNUa4uNkYuV41roLmeFlQVroCyB70sJgp0HPU4V wzYiUBaaxsbCr48IlafSPi/YoMuW2XT3zKWAatOvfl9MXt8ZXO7KoO1/KPUU23CHQZLY Rq8Q==
X-Gm-Message-State: AIkVDXIR+WIL00MjACitoND+7PvuUKcLoiyVPp/lAONmQTF9v3WYPhfyGlhDRUR605DTIGlwoqTRoRqvaz/PKA==
X-Received: by 10.237.55.97 with SMTP id i88mr61105770qtb.143.1483497403070; Tue, 03 Jan 2017 18:36:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.38.233 with HTTP; Tue, 3 Jan 2017 18:36:42 -0800 (PST)
In-Reply-To: <1b678d65-b146-b25f-c1ad-6dfc044f7ce0@akamai.com>
References: <0DA64421-5975-4B7E-BC08-7428AFA9D1A1@vigilsec.com>  <9D8BEE12-49F9-4DE3-81C7-909CB114805F@vigilsec.com> <1b678d65-b146-b25f-c1ad-6dfc044f7ce0@akamai.com>
From: Martin Thomson 
Date: Wed, 4 Jan 2017 13:36:42 +1100
Message-ID: 
To: Benjamin Kaduk 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: IETF TLS 
Subject: Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 04 Jan 2017 02:36:45 -0000

On 4 January 2017 at 12:02, Benjamin Kaduk  wrote:
> I also had the sense that ekr noted that we didn't want to do this in the
> core spec.
> So, could you point me more clearly at what you would want to change in the
> core spec that would allow doing the thing you want to see done in a future
> document?  (Is it just removing "i.e., when a PSK is not in use"?)

I for one am interested in having a mode that allows for PSK+cert, but
it's hard to reason through.  It falls into the same bucket as
additive *server* authentication, which has the same inherent
problems.  Foremost being a solid analysis.

Mechanically, it is fairly simple to add as an extension.  That makes
me confident that we can do this later.


From nobody Tue Jan  3 20:29:18 2017
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 1B438129532 for ; Tue,  3 Jan 2017 20:29:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5
X-Spam-Level: 
X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.1] 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 y253VWQhEtgd for ; Tue,  3 Jan 2017 20:29:15 -0800 (PST)
Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 03D7A129530 for ; Tue,  3 Jan 2017 20:29:14 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id CA8B8146C9; Wed,  4 Jan 2017 06:29:12 +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-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id HRQbHGGMNC_1; Wed,  4 Jan 2017 06:29:12 +0200 (EET)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 2E54421C; Wed,  4 Jan 2017 06:29:12 +0200 (EET)
Date: Wed, 4 Jan 2017 06:29:01 +0200
From: Ilari Liusvaara 
To: Benjamin Kaduk 
Message-ID: <20170104042901.GA21843@LK-Perkele-V2.elisa-laajakaista.fi>
References:  <79db4a88-e435-2e5b-47a5-9048acef45e2@cs.tcd.ie>  <582703ab-4340-35e7-a3d2-45dd606f10a1@cs.tcd.ie>   <20161230124420.GA11229@LK-Perkele-V2.elisa-laajakaista.fi> <5e06f30a-2f29-0c1f-432b-ed02c7f6c5ae@akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <5e06f30a-2f29-0c1f-432b-ed02c7f6c5ae@akamai.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Cc: Adam Langley , "tls@ietf.org" 
Subject: Re: [TLS] cross-domain cache sharing and 0rtt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 04 Jan 2017 04:29:17 -0000

On Tue, Jan 03, 2017 at 06:14:23PM -0600, Benjamin Kaduk wrote:
> On 12/30/2016 06:44 AM, Ilari Liusvaara wrote:
> > On Thu, Dec 29, 2016 at 02:45:53PM -0800, Adam Langley wrote:
> >>
> >> An attacker could redirect a 0-RTT handshake that was destined to S1
> >> and feed it to S2. If S2 ignores the SNI value (common) it could
> >> accept and process the 0-RTT data even though it was destined for S1.
> > Sounds like standard-issue default-vhost attack (which are sadly
> > common security issues in https://).
> >  
> 
> Somehow, I feel like adding text in the 1.3 spec that servers should not
> do this is not really going to help anyone.

I think it is much more HTTP-layer issue than TLS issue. After all, the
authoritative vhost info is available on HTTP layer. The TLS layer info
is not authoritative, especially in HTTP/2.

The last point is especially as coalescing information in HTTP/2 can
not be considered authenticatied (so attacker can trigger coalescing).

> >> However, in that case TLS 1.2 is probably also affected because S2
> >> would likely process a 1.2 handshake that was destined to S1 as well.
> >> (Even without a shared ticket key or session cache.) See
> >> http://antoine.delignat-lavaud.fr/doc/www15.pdf for more.
> > You mean redirecting full handshake meant for s1.example.com to
> > s2.example.com? Or redirecting a TLS 1.2 resumption handshake?
> 
> Naively, if s1 and s2 share cert and private key, and ignore the SNI, it
> seems like redirecting a full handshake would work.  But I didn't think
> about it very hard.

Actually, I think it would work if you merely have cross-valid 
selected certs. No need to share private key or even ignore SNI.

I'm aware of at least one TLS library that under no circumstances
ignores SNI for certificate selection (SNI with no known certificate
is always fatal error, and the returned certificate is always valid for
the name in SNI), but still can have redirect full handshakes if both
sides merely have a certificate that is valid for the other (no need
to share a key).



-Ilari


From nobody Tue Jan  3 20:38:28 2017
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 1629B129537 for ; Tue,  3 Jan 2017 20:38:27 -0800 (PST)
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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 JklNoT4QgWca for ; Tue,  3 Jan 2017 20:38:25 -0800 (PST)
Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 4F760129533 for ; Tue,  3 Jan 2017 20:38:25 -0800 (PST)
Received: by mail-qt0-x230.google.com with SMTP id v23so13018780qtb.0 for ; Tue, 03 Jan 2017 20:38:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3tdTXtRSrbG5F48M8PHqPgilzP+X0S9kgF7jtt73j7o=; b=fC+65bKzDnLrE0kIo9eCZcB31Yn3eIf3KhDS4uFtVWclECeiu9XcWysCnALiqsWiSF CXVu2hAxQahU9k4quqjws9mTxltSNKUEfDnv+KaEtBvVtDYnRkC5qomJSkrh5mqDyeD+ Xo8GvR21OYSiQkeou7RY75t0OZzqz5UaJuJkYFC97+o1dcALZj62ixDrP+42uMrIhImD uonl+utADCTNITGm1ricKlWlc8km2SWxCdm7+AGY1Wj+UUdwfFbaWU0MMOyNro6mhcAO 2/seafU2z9lwHNSUHfZ02UUeDRsZRQs28QjTrSjLk0oPDuJjcaKqMB3+vZ21t+wUA9sM Q2fg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3tdTXtRSrbG5F48M8PHqPgilzP+X0S9kgF7jtt73j7o=; b=d7EMtwjEtRm2S/duZyCrOjI8b7DA6pGgeagkQHtB4Qjuy3F3GZD8m8tTPylz8aBDHQ UwfUEdauFdAJqvpeJYa9t2ONK37VC8dFCCXchBjbuk9csJFNGprK2+UUd/T0tSlqC+VO i4qYu27itHw2ELs+enLttWtpxEvrhKhg08s7CKgiPrOBqUHGeTHom7oXcHirsBCoY4d/ iFiYSbupMocTnlRzT7ExGAsBp+KkAjHAobdo6fZ4Vq+MvMJFJkhYpJdHlVw09jNzs7i2 bUx+M6fpPt/rXKYXKVwWVuj7u9yZUCvYJAmfAam+OjxdTrA03WHZ9QkciLxlSpMKlguO 8MvQ==
X-Gm-Message-State: AIkVDXLo4Dpgv7nf/7ainjgwDPDWEKQ00XC7WdL6Y6XwzhCX+9sZHH+0VHPY6mlSnGRxlMwmo/D1gBNI6I9MPw==
X-Received: by 10.200.35.14 with SMTP id a14mr59661027qta.159.1483504704423; Tue, 03 Jan 2017 20:38:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.38.233 with HTTP; Tue, 3 Jan 2017 20:38:23 -0800 (PST)
In-Reply-To: <20170104042901.GA21843@LK-Perkele-V2.elisa-laajakaista.fi>
References:  <79db4a88-e435-2e5b-47a5-9048acef45e2@cs.tcd.ie>  <582703ab-4340-35e7-a3d2-45dd606f10a1@cs.tcd.ie>   <20161230124420.GA11229@LK-Perkele-V2.elisa-laajakaista.fi> <5e06f30a-2f29-0c1f-432b-ed02c7f6c5ae@akamai.com> <20170104042901.GA21843@LK-Perkele-V2.elisa-laajakaista.fi>
From: Martin Thomson 
Date: Wed, 4 Jan 2017 15:38:23 +1100
Message-ID: 
To: Ilari Liusvaara 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: Adam Langley , "tls@ietf.org" 
Subject: Re: [TLS] cross-domain cache sharing and 0rtt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 04 Jan 2017 04:38:27 -0000

On 4 January 2017 at 15:29, Ilari Liusvaara  wrote:
>> Naively, if s1 and s2 share cert and private key, and ignore the SNI, it
>> seems like redirecting a full handshake would work.  But I didn't think
>> about it very hard.
>
> Actually, I think it would work if you merely have cross-valid
> selected certs. No need to share private key or even ignore SNI.

That's almost ignoring SNI.  You are X but will accept a connection
for Y.  It's certainly true that you don't need to share keys, you
share valid credentials and are willing to use them.

Either way, your point is well made.  How servers identify themselves
is bound up in how they expect to be identified, which is often
ambiguous intentionally.

For example, it's common to have a single deployment configuration
across an entire cluster and to rely on SNI alone for picking a
certificate.  That way you simplify management and don't have to look
at IP addresses or anything like that.


From nobody Tue Jan  3 20:40:47 2017
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 E6168129BC7; Tue,  3 Jan 2017 20:40:42 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.40.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148350484293.27937.4843793552940028392.idtracker@ietfa.amsl.com>
Date: Tue, 03 Jan 2017 20:40:42 -0800
Archived-At: 
Cc: tls@ietf.org
Subject: [TLS] I-D Action: draft-ietf-tls-tls13-vectors-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 04 Jan 2017 04:40:43 -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 of the IETF.

        Title           : Example Handshake Traces for TLS 1.3
        Author          : Martin Thomson
	Filename        : draft-ietf-tls-tls13-vectors-00.txt
	Pages           : 40
	Date            : 2017-01-03

Abstract:
   Examples of TLS 1.3 handshakes are shown.  Private keys and inputs
   are provided so that these handshakes might be reproduced.
   Intermediate values, including secrets, traffic keys and ivs are
   shown so that implementations might be checked incrementally against
   these values.


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-tls-tls13-vectors-00


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 Jan  3 20:54:36 2017
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 8C0DC129BC5 for ; Tue,  3 Jan 2017 20:54:35 -0800 (PST)
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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 WHKYl9RvCk7O for ; Tue,  3 Jan 2017 20:54:34 -0800 (PST)
Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::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 0C658129536 for ; Tue,  3 Jan 2017 20:54:34 -0800 (PST)
Received: by mail-qk0-x22a.google.com with SMTP id n21so390749235qka.3 for ; Tue, 03 Jan 2017 20:54:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=xHFtkqxx+UNSofCvFVk/CSkqdG7Z3LGFcUiob1C9gdQ=; b=mZc9wnIcanRY106oHD8+w/8uNdcpKxYbkw9SFY4dnRdC18TY+JvKt6Vh7AGs+vss8a XwxCLF289aXvEKC8ofRs07b5zc+F8jhQAxvVDOhaxBIg4Mih9Lhg+toUer4FA4EB3+ih 6eQQp99TqNGh/Sv6GBfwzOixT1FfVydK4eAyBr2CtSYfsj00WIngq6bwYuL/flBOGioQ YeCDgOSwi/bt/3ktrSZnNVBJnVIxyP/C+wH5xTqSFxkmNScLwN04lZYJ6esraYb3/NJT Mx9I89L07tnHfPMfIFYttQ/FNCg5c2dK+/qT8dnsjRlVbvL7ojrs6ayEZGQMWLd7QToM OrSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=xHFtkqxx+UNSofCvFVk/CSkqdG7Z3LGFcUiob1C9gdQ=; b=bLn9gTOK/ZLRzfcQ6+3OPW4lXx5eXXx/8K/JLQIfsLGZ2wqiMlBNieQ0yg7p/TCUKj l3DtLxm0av5aYuVmJBQJPwMmpVfC6S9KvxDO7pCuMOIvdHSI8l/fmpoTQHa81nYO2XzO pRQgg3oK71uRfPYPQnXCZfxzZR/UUSkF+LZE00IwQl77uZe2BhFoG94BFCqR/j4VtpMB U2Vo6XxtmyV38emafhA5hxaoXTrEMtOpHalabw+suhLhTKLiwjO6TAcCU/AU7haWWKAF yrX8IIci5HTrCE2jYU24+LIvJID9zq1OcznAMIxH0PC6gGhMBwj0/UzorW/oo7B+II7W ABJQ==
X-Gm-Message-State: AIkVDXKfIDEVYI4i/UlRYayxAeannM+7XKt2yEQY/+twbzcseaOahhYHZj+91SMu3YkNlBFLAEozNxP7pks72w==
X-Received: by 10.55.21.84 with SMTP id f81mr69148624qkh.5.1483505673185; Tue, 03 Jan 2017 20:54:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.38.233 with HTTP; Tue, 3 Jan 2017 20:54:32 -0800 (PST)
In-Reply-To: 
References: 
From: Martin Thomson 
Date: Wed, 4 Jan 2017 15:54:32 +1100
Message-ID: 
To: Sean Turner 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "" 
Subject: Re: [TLS] adopted: draft-thomson-tls-tls13-vectors
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 04 Jan 2017 04:54:35 -0000

And it is done.  I fluffed one change: NSS supports exporters now.
I'll catch that when there is cause to generate a new version.

PRs and issues can be opened here:
https://github.com/tlswg/draft-ietf-tls-tls13-vectors

The editor's copy is here: https://tlswg.github.io/draft-ietf-tls-tls13-vec=
tors/

On 4 January 2017 at 00:59, Sean Turner  wrote:
> I appears that we=E2=80=99ve got enough consensus/interest to adopt draft=
-thomson-tls-tls13-vectors based on this thread:
> https://mailarchive.ietf.org/arch/msg/tls/LOS06OPDeLOrdtE8QoBLXEHO51s
>
> Martin,
>
> Please submit draft-ietf-tls-tls13-vectors at your earliest convenience. =
 I=E2=80=99ll set up a tlswg repo in just a sec.
>
> Thanks!
>
> J&S
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From nobody Tue Jan  3 20:59:29 2017
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 D0CAD129BCA for ; Tue,  3 Jan 2017 20:59:27 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.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 acXAEC6WjWGK for ; Tue,  3 Jan 2017 20:59:26 -0800 (PST)
Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 55F82129536 for ; Tue,  3 Jan 2017 20:59:26 -0800 (PST)
Received: by mail-io0-x22e.google.com with SMTP id p42so446954780ioo.1 for ; Tue, 03 Jan 2017 20:59:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=z56Dw9bUn8XH0nfzd/NJ2LaxO3+PRLVmbjJicKbvGrc=; b=PbO3HZGtc2wdOuu/1QZs6wVUhLDRJDlcqH/LITaGsKFbdiQ0wqWKIPVPJIHB8opSJC aUzWNTWtlUJMFyhG4IC3FvVbPY01FU6j1BwU2uz/87wwVkZrLI74zo6pMPilKg5TGt3H iMo62lA9qIU8Jx+5FzgYw6vtWcQx54XcweixKlCq6FlRBEo4gabT1MugArWYd8DvY6h+ hFClv0BFc3KOgnt3oxM0ylrrEL7Z4Wqea56TAy7Z//+V5rayADGMJLDC5jL0Ol7WM9R5 vStC0opG061OXxsvuroZrDeMyLTZfJPOblTzPckgxjh2FxTN4GPk6Q5C9sxjUwpEgLDy Q4LA==
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=z56Dw9bUn8XH0nfzd/NJ2LaxO3+PRLVmbjJicKbvGrc=; b=YiXbqsNNiuMBvkHVj9ZcOLd0M7KY7xE63Y1qG/PnNGZ9Xgn22putVwn4hn7RtE8FlU f5KOC2MgKsN/mdUkhNzoBxfoRImhNLAxbYMsdPC8OGNq6ixWXvqZmdXQq43FY3LUSkUj NVYPpoCqkc/w1dW1HYo4p0ihdgebvoNkIgdTRpHEamClv3tszr/bxwkV5HkUkcJUwaeo VwBnPCKoDfGrZ6Y6n6/ODgeNgbdgAQ5jyTNTZTyd0WgQTLEBbGQRKzqWN3CX320BUKOt 6MGGzzkgsEtkf+MpCbf8I/BlkP6h77Er73HEE2FDa90w0Q+rzr9wViRwtTZzHryTp2cd PEfg==
X-Gm-Message-State: AIkVDXILGzkcpfH4HfdU3riPoFBnF0fuTFH0jQhc6tWKXUYiXubyQzyaT3R3diiwdOUG4wnn6JGmtZBimAV9MA==
X-Received: by 10.107.29.148 with SMTP id d142mr57014060iod.44.1483505965422;  Tue, 03 Jan 2017 20:59:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.79.15.73 with HTTP; Tue, 3 Jan 2017 20:59:05 -0800 (PST)
From: Joseph Salowey 
Date: Tue, 3 Jan 2017 20:59:05 -0800
Message-ID: 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a114089c417856205453da624
Archived-At: 
Subject: [TLS] Interest in draft-sullivan-tls-exported-authentication
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 04 Jan 2017 04:59:28 -0000

--001a114089c417856205453da624
Content-Type: text/plain; charset=UTF-8

There seemed to be support for draft-sullivan-tls-exported-authentication (
https://tools.ietf.org/html/draft-sullivan-tls-exported-authenticator-00)
in Seoul.   Since there has not been much discussion of this draft on the
list we are giving the working group a chance to review the draft before
calling for adoption later this month.

Cheers,

J&S

--001a114089c417856205453da624
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


There seemed to be suppor=
t for=C2=A0draft-sullivan-tls-exported-authentication (https://tools.ietf.org/html/dra=
ft-sullivan-tls-exported-authenticator-00) in Seoul. =C2=A0 Since there has not been much discussion of this=
 draft on the list we are giving the working group a chance to review the d=
raft before calling for adoption later this month. =C2=A0=C2=A0

Cheers=
,

J&S


--001a114089c417856205453da624--


From nobody Wed Jan  4 13:16:23 2017
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 0C962129637 for ; Wed,  4 Jan 2017 13:16:22 -0800 (PST)
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] 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 8wk4dXpybWQ7 for ; Wed,  4 Jan 2017 13:16:20 -0800 (PST)
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 66CF61296C6 for ; Wed,  4 Jan 2017 13:16:20 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id F2E1D300431 for ; Wed,  4 Jan 2017 16:06:03 -0500 (EST)
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 keXf3kKXPfta for ; Wed,  4 Jan 2017 16:06:02 -0500 (EST)
Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 23001300408; Wed,  4 Jan 2017 16:06:02 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_D96BD6F3-CA0E-4047-8D4A-C69DFFDCC173"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: <1b678d65-b146-b25f-c1ad-6dfc044f7ce0@akamai.com>
Date: Wed, 4 Jan 2017 16:17:07 -0500
Message-Id: <0FDAC302-2E1E-4E31-B649-2E2E0B4EB690@vigilsec.com>
References: <0DA64421-5975-4B7E-BC08-7428AFA9D1A1@vigilsec.com>  <9D8BEE12-49F9-4DE3-81C7-909CB114805F@vigilsec.com> <1b678d65-b146-b25f-c1ad-6dfc044f7ce0@akamai.com>
To: Benjamin Kaduk 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: IETF TLS 
Subject: Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 04 Jan 2017 21:16:22 -0000

--Apple-Mail=_D96BD6F3-CA0E-4047-8D4A-C69DFFDCC173
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Ben:

> I also had the sense that ekr noted that we didn't want to do this in =
the core spec.
> So, could you point me more clearly at what you would want to change =
in the core spec that would allow doing the thing you want to see done =
in a future document?  (Is it just removing "i.e., when a PSK is not in =
use"?)
>=20

I am not looking to put the details in the core spec.  I think I said =
that in my first posting.  However, I do want to ensure that the =
identity associated with the external PSK and the certificate are both =
considered.  There needs to be a hook in the core spec for that to =
happen.

I quotes the part of the core spec that seems to say otherwise.


>>> On Thu, Dec 22, 2016 at 4:54 PM Russ Housley  =
wrote:
>>> I want to make sure that it is possible to mix PSK with (EC)DH as a =
protection against the discovery of a quantum computer.  I recognize =
that the WG does not want to tackle this topic in the base =
specification; however, the following text in Section 4.1.1 makes this =
difficult to do so in a companion document:
>>>=20
>>> >    The server indicates its selected parameters in the ServerHello =
as
>>> >    follows:
>>> >
>>> >    -  If PSK is being used then the server will send a =
"pre_shared_key"
>>> >       extension indicating the selected key.
>>> >
>>> >    -  If PSK is not being used, then (EC)DHE and certificate-based
>>> >       authentication are always used.
>>> >
>>> >    -  When (EC)DHE is in use, the server will also provide a =
"key_share"
>>> >       extension.
>>> >
>>> >    -  When authenticating via a certificate (i.e., when a PSK is =
not in
>>> >       use), the server will send the Certificate (Section 4.4.1) =
and
>>> >       CertificateVerify (Section 4.4.2) messages.

Russ=

--Apple-Mail=_D96BD6F3-CA0E-4047-8D4A-C69DFFDCC173
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=windows-1252

Ben:


  
    
  
  

    I also had the sense that ekr noted that we didn't want to do
      this in the core spec.

      So, could you point me more clearly at what you would want to
      change in the core spec that would allow doing the thing you want
      to see done in a future document?  (Is it just removing "i.e.,
      when a PSK is not in use"?)

      

I am not looking to put the details in the core spec.  I think I said that in my first posting.  However, I do want to ensure that the identity associated with the external PSK and the certificate are both considered.  There needs to be a hook in the core spec for that to happen.

I quotes the part of the core spec that seems to say otherwise.


On Thu, Dec 22, 2016 at 4:54 PM Russ
                      Housley <housley@vigilsec.com>
                      wrote:

                    
I want to make
                      sure that it is possible to mix PSK with (EC)DH as
                      a protection against the discovery of a quantum
                      computer.  I recognize that the WG does not want
                      to tackle this topic in the base specification;
                      however, the following text in Section 4.1.1 makes
                      this difficult to do so in a companion document:

                      

                      >    The server indicates its selected
                      parameters in the ServerHello as

                      >    follows:

                      >

                      >    -  If PSK is being used then the server
                      will send a "pre_shared_key"

                      >       extension indicating the selected key.

                      >

                      >    -  If PSK is not being used, then (EC)DHE
                      and certificate-based

                      >       authentication are always used.

                      >

                      >    -  When (EC)DHE is in use, the server will
                      also provide a "key_share"

                      >       extension.

                      >

                      >    -  When authenticating via a certificate
                      (i.e., when a PSK is not in

                      >       use), the server will send the
                      Certificate (Section 4.4.1) and

                      >       CertificateVerify (Section 4.4.2)
                      messages.

Russ

--Apple-Mail=_D96BD6F3-CA0E-4047-8D4A-C69DFFDCC173--


From nobody Wed Jan  4 13:23:58 2017
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 141611296EF for ; Wed,  4 Jan 2017 13:23:57 -0800 (PST)
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] 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 3mj26M-2wDr2 for ; Wed,  4 Jan 2017 13:23:56 -0800 (PST)
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 049021296D4 for ; Wed,  4 Jan 2017 13:23:56 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id BDE9330041F for ; Wed,  4 Jan 2017 16:13:39 -0500 (EST)
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 WfDiVUJVI2Mw for ; Wed,  4 Jan 2017 16:13:38 -0500 (EST)
Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id B1D0D30042B; Wed,  4 Jan 2017 16:13:38 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: 
Date: Wed, 4 Jan 2017 16:23:20 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <733EE968-69EF-43A5-A39B-F016993A3CCD@vigilsec.com>
References: <0DA64421-5975-4B7E-BC08-7428AFA9D1A1@vigilsec.com>  <9D8BEE12-49F9-4DE3-81C7-909CB114805F@vigilsec.com> <1b678d65-b146-b25f-c1ad-6dfc044f7ce0@akamai.com> 
To: Martin Thomson 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: IETF TLS 
Subject: Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 04 Jan 2017 21:23:57 -0000

On Jan 3, 2017, at 9:36 PM, Martin Thomson  =
wrote:

> On 4 January 2017 at 12:02, Benjamin Kaduk  wrote:
>> I also had the sense that ekr noted that we didn't want to do this in =
the
>> core spec.
>> So, could you point me more clearly at what you would want to change =
in the
>> core spec that would allow doing the thing you want to see done in a =
future
>> document?  (Is it just removing "i.e., when a PSK is not in use"?)
>=20
> I for one am interested in having a mode that allows for PSK+cert, but
> it's hard to reason through.  It falls into the same bucket as
> additive *server* authentication, which has the same inherent
> problems.  Foremost being a solid analysis.
>=20
> Mechanically, it is fairly simple to add as an extension.  That makes
> me confident that we can do this later.

Mee too.  At this point, the spec calls for the identity to come from =
the PSK or the certificate.  I think there needs to be a hook in the =
document for the identity to come from a combination of the PSK and the =
certificate.  I recognize this is a forward pointer to stuff that is not =
yet sorted out.

Russ


From nobody Wed Jan  4 13:48:29 2017
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 68CE7129704 for ; Wed,  4 Jan 2017 13:48:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.8
X-Spam-Level: 
X-Spam-Status: No, score=-5.8 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_LOW=-0.7, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 2fYkJFR2rDKj for ; Wed,  4 Jan 2017 13:48:27 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB6E129690 for ; Wed,  4 Jan 2017 13:48:27 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5AD1243341D; Wed,  4 Jan 2017 21:48:26 +0000 (GMT)
Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 37B2443340E; Wed,  4 Jan 2017 21:48:26 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1483566506; bh=ZmhZqyyGehq2Mg1qmsE68UXrd0oJCpsInHgitKjIi/o=; l=4959; h=To:References:Cc:From:Date:In-Reply-To:From; b=us9U7N+ARFiQ0bhd2e3/2oRW+dn808FxZhoCMJjWJJR3zhuHAPUm10Xs3pfzu7wh7 6W1XMAVJTLD1B9NIDGjqB0YjMyXkQJLQIyNbj8pEq+LT/ISLLc3YyMngu2o0AKVLO8 8438VYpYK5SoKJ27pN1FNl7XWVvyLddQ/FXb+eYo=
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id E0D791FC88; Wed,  4 Jan 2017 21:48:25 +0000 (GMT)
To: Martin Thomson , Ilari Liusvaara 
References:  <79db4a88-e435-2e5b-47a5-9048acef45e2@cs.tcd.ie>  <582703ab-4340-35e7-a3d2-45dd606f10a1@cs.tcd.ie>   <20161230124420.GA11229@LK-Perkele-V2.elisa-laajakaista.fi> <5e06f30a-2f29-0c1f-432b-ed02c7f6c5ae@akamai.com> <20170104042901.GA21843@LK-Perkele-V2.elisa-laajakaista.fi> 
From: Benjamin Kaduk 
X-Enigmail-Draft-Status: N1110
Message-ID: 
Date: Wed, 4 Jan 2017 15:48:25 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------9D3CC68178328FA5191D4BE7"
Archived-At: 
Cc: Adam Langley , "tls@ietf.org" 
Subject: Re: [TLS] cross-domain cache sharing and 0rtt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 04 Jan 2017 21:48:28 -0000

This is a multi-part message in MIME format.
--------------9D3CC68178328FA5191D4BE7
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On 01/03/2017 10:38 PM, Martin Thomson wrote:
> On 4 January 2017 at 15:29, Ilari Liusvaara  wrote:
>>> Naively, if s1 and s2 share cert and private key, and ignore the SNI, it
>>> seems like redirecting a full handshake would work.  But I didn't think
>>> about it very hard.
>> Actually, I think it would work if you merely have cross-valid
>> selected certs. No need to share private key or even ignore SNI.
> That's almost ignoring SNI.  You are X but will accept a connection
> for Y.  It's certainly true that you don't need to share keys, you
> share valid credentials and are willing to use them.
>
> Either way, your point is well made.  How servers identify themselves
> is bound up in how they expect to be identified, which is often
> ambiguous intentionally.
>
> For example, it's common to have a single deployment configuration
> across an entire cluster and to rely on SNI alone for picking a
> certificate.  That way you simplify management and don't have to look
> at IP addresses or anything like that.

It seems like we're violently agreeing with each other, here, and should
settle on text to go (or not go) into the security considerations
section.  In the interest of sparking discussion, I propose the strawman:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

When a server has valid credentials for multiple server names, and at
least one of those names could also be served by valid credentials on a
different server, it may be possible for an attacker
to replay traffic from a client intended for the second server against
the first server, including 0-RTT data.  This behavior can be avoided if
the server knows what server name is expected for a given request (e.g.,
via an HTTP Host header) and verifies that the supplied SNI extension
matches the expected server name, though in some cases the mismatch is
harmless.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Though, to be honest, I'm not even 100% convinced that we need to add
new text.

-Ben

--------------9D3CC68178328FA5191D4BE7
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    On 01/03/2017 10:38 PM, Martin Thomson wrote:

    

      
On 4 January 2017 at 15:29, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:


      

        

          
Naively, if s1 and s2 share cert and private key, and ignore the SNI, it
seems like redirecting a full handshake would work.  But I didn't think
about it very hard.


        

        
Actually, I think it would work if you merely have cross-valid
selected certs. No need to share private key or even ignore SNI.


      

      
That's almost ignoring SNI.  You are X but will accept a connection
for Y.  It's certainly true that you don't need to share keys, you
share valid credentials and are willing to use them.

Either way, your point is well made.  How servers identify themselves
is bound up in how they expect to be identified, which is often
ambiguous intentionally.

For example, it's common to have a single deployment configuration
across an entire cluster and to rely on SNI alone for picking a
certificate.  That way you simplify management and don't have to look
at IP addresses or anything like that.


    

    

    It seems like we're violently agreeing with each other, here, and
    should settle on text to go (or not go) into the security
    considerations section.  In the interest of sparking discussion, I
    propose the strawman:

    

    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

    

    When a server has valid credentials for multiple server names, and
    at least one of those names could also be served by valid
    credentials on a different server, it may be possible for an
    attacker

    to replay traffic from a client intended for the second server
    against the first server, including 0-RTT data.  This behavior can
    be avoided if the server knows what server name is expected for a
    given request (e.g., via an HTTP Host header) and verifies that the
    supplied SNI extension matches the expected server name, though in
    some cases the mismatch is harmless.

    

    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

    

    Though, to be honest, I'm not even 100% convinced that we need to
    add new text.

    

    -Ben

  


--------------9D3CC68178328FA5191D4BE7--


From nobody Wed Jan  4 17:33:35 2017
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 C10B21294AB for ; Wed,  4 Jan 2017 17:33:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.8
X-Spam-Level: 
X-Spam-Status: No, score=-5.8 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_LOW=-0.7, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 m5DZ9eXu3W9U for ; Wed,  4 Jan 2017 17:33:31 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 377E21293DC for ; Wed,  4 Jan 2017 17:33:31 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BD12A433412; Thu,  5 Jan 2017 01:33:30 +0000 (GMT)
Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id A5F5C433404; Thu,  5 Jan 2017 01:33:30 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1483580010; bh=CNuPihA6TNnd5lhsoV6x/D3EUkfhXu7mbWa8DUyk35I=; l=7770; h=To:References:Cc:From:Date:In-Reply-To:From; b=zg4C+FTlmrZd9gV1jm9kvO2ak6B9Plz67eGHc8l4ZV+NwlkYm1soBDdYrCcPjwRbP HQqC9KnVUyxrbEVbTW3InxBf7ToWdIh+ufIU3jq1saHnK5s0B6R0yl6jEKhEPRcQ8z PotwjNk0BrOqwNwKKPvfuEoV77b8vBpHHCTMx5U4=
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 599FB1FC86; Thu,  5 Jan 2017 01:33:30 +0000 (GMT)
To: Russ Housley 
References: <0DA64421-5975-4B7E-BC08-7428AFA9D1A1@vigilsec.com>  <9D8BEE12-49F9-4DE3-81C7-909CB114805F@vigilsec.com> <1b678d65-b146-b25f-c1ad-6dfc044f7ce0@akamai.com> <0FDAC302-2E1E-4E31-B649-2E2E0B4EB690@vigilsec.com>
From: Benjamin Kaduk 
Message-ID: <62a479bc-895f-8b59-e37d-5854bfe1185c@akamai.com>
Date: Wed, 4 Jan 2017 19:33:30 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <0FDAC302-2E1E-4E31-B649-2E2E0B4EB690@vigilsec.com>
Content-Type: multipart/alternative; boundary="------------025FC0AE98C810FD2D30B245"
Archived-At: 
Cc: IETF TLS 
Subject: Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 05 Jan 2017 01:33:34 -0000

This is a multi-part message in MIME format.
--------------025FC0AE98C810FD2D30B245
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit

Hi Russ,

On 01/04/2017 03:17 PM, Russ Housley wrote:
> Ben:
>
>> I also had the sense that ekr noted that we didn't want to do this in
>> the core spec.
>> So, could you point me more clearly at what you would want to change
>> in the core spec that would allow doing the thing you want to see
>> done in a future document?  (Is it just removing "i.e., when a PSK is
>> not in use"?)
>>
>
> I am not looking to put the details in the core spec.  I think I said
> that in my first posting.  However, I do want to ensure that the
> identity associated with the external PSK and the certificate are both
> considered.  There needs to be a hook in the core spec for that to happen.
>

I understand that.

> I quotes the part of the core spec that seems to say otherwise.
>

What I don't understand is exactly which part or parts in combination of
the quoted text are saying otherwise, in your reading of it.  I offered
a potential part of the quoted text which might be leading you to that
interpretation (the "i.e., when a PSK is not in use" clause), and you
did not confirm or deny my guess.  So, I still don't understand what
seems problematic to you about the existing text -- to me, it says that
certain things must be done if certain other things are or are not done,
but does not seem to preclude certain things being done and certain
other things also being done. Maybe you could propose a patch that
provides the hook that you would like to see, so that I can understand
the issue with the current text?

-Ben

>
>>>> On Thu, Dec 22, 2016 at 4:54 PM Russ Housley >>> > wrote:
>>>>
>>>>     I want to make sure that it is possible to mix PSK with (EC)DH
>>>>     as a protection against the discovery of a quantum computer.  I
>>>>     recognize that the WG does not want to tackle this topic in the
>>>>     base specification; however, the following text in Section
>>>>     4.1.1 makes this difficult to do so in a companion document:
>>>>
>>>>     >    The server indicates its selected parameters in the
>>>>     ServerHello as
>>>>     >    follows:
>>>>     >
>>>>     >    -  If PSK is being used then the server will send a
>>>>     "pre_shared_key"
>>>>     >       extension indicating the selected key.
>>>>     >
>>>>     >    -  If PSK is not being used, then (EC)DHE and
>>>>     certificate-based
>>>>     >       authentication are always used.
>>>>     >
>>>>     >    -  When (EC)DHE is in use, the server will also provide a
>>>>     "key_share"
>>>>     >       extension.
>>>>     >
>>>>     >    -  When authenticating via a certificate (i.e., when a PSK
>>>>     is not in
>>>>     >       use), the server will send the Certificate (Section
>>>>     4.4.1) and
>>>>     >       CertificateVerify (Section 4.4.2) messages.
>>>>
>
> Russ


--------------025FC0AE98C810FD2D30B245
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hi Russ,

    

    
On 01/04/2017 03:17 PM, Russ Housley
      wrote:

    

    

      
      Ben:

      


        

          
 I also had the
              sense that ekr noted that we didn't want to do this in the
              core spec.

              So, could you point me more clearly at what you would want
              to change in the core spec that would allow doing the
              thing you want to see done in a future document? (Is it
              just removing "i.e., when a PSK is not in use"?)

              

            

        

        


        

        I am not looking to put the details in the core spec. I think I
        said that in my first posting. However, I do want to ensure
        that the identity associated with the external PSK and the
        certificate are both considered. There needs to be a hook in
        the core spec for that to happen.

      


      

    

    

    I understand that.

    

    

      
I quotes the part of the core spec that seems to say
        otherwise.

      


      

    

    

    What I don't understand is exactly which part or parts in
    combination of the quoted text are saying otherwise, in your reading
    of it. I offered a potential part of the quoted text which might be
    leading you to that interpretation (the "i.e., when a PSK is not in
    use" clause), and you did not confirm or deny my guess. So, I still
    don't understand what seems problematic to you about the existing
    text -- to me, it says that certain things must be done if certain
    other things are or are not done, but does not seem to preclude
    certain things being done and certain other things also being done.
    Maybe you could propose a patch that provides the hook that you
    would like to see, so that I can understand the issue with the
    current text?

    

    -Ben

    

    

      


        

          

            

              

                

                  

                    

                      

                        
On Thu, Dec 22, 2016 at 4:54 PM Russ
                          Housley <housley@vigilsec.com>
                          wrote:

                          

                            
I want to make
                              sure that it is possible to mix PSK with
                              (EC)DH as a protection against the
                              discovery of a quantum computer. I
                              recognize that the WG does not want to
                              tackle this topic in the base
                              specification; however, the following text
                              in Section 4.1.1 makes this difficult to
                              do so in a companion document:

                              

                              >  The server indicates its selected
                              parameters in the ServerHello as

                              >  follows:

                              >

                              >  - If PSK is being used then the
                              server will send a "pre_shared_key"

                              >   extension indicating the
                              selected key.

                              >

                              >  - If PSK is not being used, then
                              (EC)DHE and certificate-based

                              >   authentication are always used.

                              >

                              >  - When (EC)DHE is in use, the
                              server will also provide a "key_share"

                              >   extension.

                              >

                              >  - When authenticating via a
                              certificate (i.e., when a PSK is not in

                              >   use), the server will send the
                              Certificate (Section 4.4.1) and

                              >   CertificateVerify (Section
                              4.4.2) messages.

                            

                          

                        

                      

                    

                  

                

              

            

          

        

      

      

      
Russ

    

    

  


--------------025FC0AE98C810FD2D30B245--


From nobody Thu Jan  5 00:05:35 2017
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 A3DE8129ADD for ; Thu,  5 Jan 2017 00:05:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5
X-Spam-Level: 
X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.1] 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 EcX80PaK62HB for ; Thu,  5 Jan 2017 00:05:31 -0800 (PST)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1271294C5 for ; Thu,  5 Jan 2017 00:05:31 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 2FC3B13D35; Thu,  5 Jan 2017 10:05:29 +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 qSuC97r2fzqS; Thu,  5 Jan 2017 10:05:28 +0200 (EET)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id D584321C; Thu,  5 Jan 2017 10:05:28 +0200 (EET)
Date: Thu, 5 Jan 2017 10:05:18 +0200
From: Ilari Liusvaara 
To: Benjamin Kaduk 
Message-ID: <20170105080518.GA23934@LK-Perkele-V2.elisa-laajakaista.fi>
References: <79db4a88-e435-2e5b-47a5-9048acef45e2@cs.tcd.ie>  <582703ab-4340-35e7-a3d2-45dd606f10a1@cs.tcd.ie>   <20161230124420.GA11229@LK-Perkele-V2.elisa-laajakaista.fi> <5e06f30a-2f29-0c1f-432b-ed02c7f6c5ae@akamai.com> <20170104042901.GA21843@LK-Perkele-V2.elisa-laajakaista.fi>  
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Cc: Adam Langley , "tls@ietf.org" 
Subject: Re: [TLS] cross-domain cache sharing and 0rtt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 05 Jan 2017 08:05:33 -0000

On Wed, Jan 04, 2017 at 03:48:25PM -0600, Benjamin Kaduk wrote:
> On 01/03/2017 10:38 PM, Martin Thomson wrote:
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> 
> When a server has valid credentials for multiple server names, and at
> least one of those names could also be served by valid credentials on a
> different server, it may be possible for an attacker
> to replay traffic from a client intended for the second server against
> the first server, including 0-RTT data.  This behavior can be avoided if
> the server knows what server name is expected for a given request (e.g.,
> via an HTTP Host header) and verifies that the supplied SNI extension
> matches the expected server name, though in some cases the mismatch is
> harmless.
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Checking that Host/:authority and SNI match does not work properly for
HTTP/2.

There, if you want to avoid default-vhost attacks, you have to check
:authority (Host) without reference to SNI.



-Ilari


From nobody Thu Jan  5 13:06:12 2017
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 DC5B6129455 for ; Thu,  5 Jan 2017 13:06:11 -0800 (PST)
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 (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 cDOE3Szx3Ozq for ; Thu,  5 Jan 2017 13:06:10 -0800 (PST)
Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 73566129584 for ; Thu,  5 Jan 2017 13:06:10 -0800 (PST)
Received: by mail-qt0-x22a.google.com with SMTP id v23so62439995qtb.0 for ; Thu, 05 Jan 2017 13:06:10 -0800 (PST)
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=ft7ilXvp+OZOyTLYTpCqmuKumRDi4Hwp3NyM/cbaarg=; b=hm2f0X6MIhJ/tkcURCmxQEqWuMgCrIXSK7Hlle7KVPxReVICFFsY9biDbG3CHVqMRj 9jx1GFjMH5huXCyrtYfKI3oHpaq9GtGtO/sF7D0RMLaIWVGulWZX9ljhLmkHx5y6erxp Q2V1YVJLGH4YVUIvbV39HEZJOlJW4qaHHV2xM=
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=ft7ilXvp+OZOyTLYTpCqmuKumRDi4Hwp3NyM/cbaarg=; b=qaoKHgM/7+GB6xUA5oU0ZRJU3yXkmXbmjRUAA9DK5b+7tEOgLfJNNr+4xPMbSw1V7e 80Ivc/y5Rr7ynveXmmPoFb8Iai8dGP3F4mcN4o6Y/Gzlme7qVIewsvQSpuYLpQO8uSnY T4mPlH0B5s2Fj8NHmx2pQg8VqAS04gXJ+Dk5mDERBoezFAzuP7cRnc5CZEbRiJw78etI ufksZqvIMqSPexNz84Ug94QeO0XUjqcK20Oha9g0tG5UtAsJDf8D2Te8xZilI+YCvb4s 7cHarinKSbAWH4pyK2hwfnvvwpO9lDTNc6MpKdph7yFTOXDB/Htyb8jhJLSlW3v9XKn0 e7rw==
X-Gm-Message-State: AIkVDXJLmvB6G4vFNf0CxYYoEMm/Bp4n2adcVu66AaP/ms2cp8mTEJf1Bwxbj4i6HN2n6w==
X-Received: by 10.200.46.123 with SMTP id s56mr66983089qta.8.1483650369520; Thu, 05 Jan 2017 13:06:09 -0800 (PST)
Received: from [172.16.0.92] (pool-173-73-120-80.washdc.east.verizon.net. [173.73.120.80]) by smtp.gmail.com with ESMTPSA id s65sm49080273qtd.2.2017.01.05.13.06.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 05 Jan 2017 13:06:08 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Sean Turner 
In-Reply-To: 
Date: Thu, 5 Jan 2017 16:06:06 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <60C134CA-ED44-4162-88EC-1BA3B3455148@sn3rd.com>
References:  
To: Martin Thomson 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: "" 
Subject: Re: [TLS] adopted: draft-thomson-tls-tls13-vectors
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 05 Jan 2017 21:06:12 -0000

Martin,

Thanks for getting this up.

spt

> On Jan 3, 2017, at 23:54, Martin Thomson  =
wrote:
>=20
> And it is done.  I fluffed one change: NSS supports exporters now.
> I'll catch that when there is cause to generate a new version.
>=20
> PRs and issues can be opened here:
> https://github.com/tlswg/draft-ietf-tls-tls13-vectors
>=20
> The editor's copy is here: =
https://tlswg.github.io/draft-ietf-tls-tls13-vectors/
>=20
> On 4 January 2017 at 00:59, Sean Turner  wrote:
>> I appears that we=E2=80=99ve got enough consensus/interest to adopt =
draft-thomson-tls-tls13-vectors based on this thread:
>> https://mailarchive.ietf.org/arch/msg/tls/LOS06OPDeLOrdtE8QoBLXEHO51s
>>=20
>> Martin,
>>=20
>> Please submit draft-ietf-tls-tls13-vectors at your earliest =
convenience.  I=E2=80=99ll set up a tlswg repo in just a sec.
>>=20
>> Thanks!
>>=20
>> J&S
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls


From nobody Fri Jan  6 13:00:33 2017
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 A5C38129ECB for ; Fri,  6 Jan 2017 13:00:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Level: 
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5] 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 kXfyd_bhcCBz for ; Fri,  6 Jan 2017 13:00:31 -0800 (PST)
Received: from smtp.smtpout.orange.fr (smtp09.smtpout.orange.fr [80.12.242.131]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64CB5129ED0 for ; Fri,  6 Jan 2017 13:00:29 -0800 (PST)
Received: from macbook-pro-de-julien-elie.home ([92.170.5.52]) by mwinf5d18 with ME id V90T1u00D17Lgi40390TBV; Fri, 06 Jan 2017 22:00:27 +0100
X-ME-Helo: macbook-pro-de-julien-elie.home
X-ME-Auth: anVsaWVuLmVsaWU0ODdAd2FuYWRvby5mcg==
X-ME-Date: Fri, 06 Jan 2017 22:00:27 +0100
X-ME-IP: 92.170.5.52
To: "tls@ietf.org" 
From: =?UTF-8?Q?Julien_=c3=89LIE?= 
Organization: TrigoFACILE -- http://www.trigofacile.com/
Message-ID: <46e42aca-69de-ca37-ae15-6515d04c1aed@trigofacile.com>
Date: Fri, 6 Jan 2017 22:00:27 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: [TLS] Obsolete TLS wording in EAP-TLS specification
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 06 Jan 2017 21:00:31 -0000

Hi all,

The EAP-TLS authentication protocol specification (RFC 5216) mentions in 
Section 2.4 that:
- "EAP-TLS implementations MUST support TLS v1.0"
- "SHOULD support TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_RC4_128_MD5"

And Sections 5.2, 5.3 and 5.4 do not give latest recommendations for 
certificate validation.

Yet, EAP-TLS is wide-spread, and notably used with WPA and WPA2.


Shouldn't it be updated in favour of following RFC 7525 (BCP for TLS) 
and RFC 6125 (guideline for certificate validation)?

-- 
Julien ÉLIE

« The following two statements are usually both true:
   There's not enough documentation.
   There's too much documentation. » (Larry Wall)


From nobody Mon Jan  9 11:56:01 2017
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 7BD9E1295A1 for ; Mon,  9 Jan 2017 11:56:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 E44YqbNEmcsl for ; Mon,  9 Jan 2017 11:55:58 -0800 (PST)
Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 AFB47129595 for ; Mon,  9 Jan 2017 11:55:58 -0800 (PST)
Received: by mail-it0-x22d.google.com with SMTP id r185so31643568ita.0 for ; Mon, 09 Jan 2017 11:55:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=aVDYrBC/faab/QWdFOIdespd5yJZzDr18TQch1COJ3Q=; b=VzFx16P4aVR7IhljIhqBbLE8nUTS09hRCyEYsbGRoTXpw/lfc81WWv5gPmLF7vpQKJ TYZCm2R0KBKDj5AV7p/NfppHpIzWedHLGvI7wgtChMaThIR18VCp4nQbMDWe3LDadMG9 7FAv47n2HEf1DoOQn3yHvQqkEnt2anRIq/2nRC3pFjWG8VZ+tA6/JotuhD8RO6ObEFDd YRfDntqaw+VJvW6da/Xl+OXEcsbchIx4GcEylWBJFl8kRtqnmuhMISLmjBJ5bHCN+gB1 uZkGhPSfWlbH1sEZPuaRXg2DXC2yBZaW9ddPiAUhopyOSxDfbCB5koicf55M/SEnDMl7 OLqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=aVDYrBC/faab/QWdFOIdespd5yJZzDr18TQch1COJ3Q=; b=c2IyuMNFi5nb+mHE4xZMjn1eJ22nmUtswtRyyxx4RT0AG5+Q/lLuk7Ogu/MNjIbJP8 xsDVG+m1ZVqFOhYt7sQCkpBLvyywp9u1sM0VCasuwm3RzzPLKlUHB3dUGd+kbEU+u45v SSSecIWltm/I6V/KjJsbjC0MM5Atdb9Hatrz59ptih8PEM2fzO6ZBG1s47t1Gr7c9pKV m/k+PZ2ywWXK/axa5IeCPlXmj9ieXTMzvadmEfjR3i4gZ3ffStppyeYWGYM4WWXl5q8J ITenJdzdV1heo8eDsMKil8EYmBwmXDLIiuk4b8KBaSc5elAc202iCD0MrLDwKxKcUT4c IJ9A==
X-Gm-Message-State: AIkVDXLuLpHSRxS4EoZ9XL4ujpSUSGSYLzwamuCw/DfQgAOsZzM3a6gFx+dSPt1Vxi+K16vefh0EgaireCPhUQ==
X-Received: by 10.36.178.74 with SMTP id h10mr10454833iti.82.1483991758003; Mon, 09 Jan 2017 11:55:58 -0800 (PST)
MIME-Version: 1.0
Sender: alangley@gmail.com
Received: by 10.36.27.136 with HTTP; Mon, 9 Jan 2017 11:55:57 -0800 (PST)
In-Reply-To: 
References:     <1483330131409.25713@cs.auckland.ac.nz> <5542029D-293A-44F5-9A11-62F5C47A4BA5@gmail.com>  <071A0098-8E03-4DCB-AA3F-4AD9424C9493@gmail.com> 
From: Adam Langley 
Date: Mon, 9 Jan 2017 14:55:57 -0500
X-Google-Sender-Auth: mFx0ARobPbWoFIKWkGr9nr91neM
Message-ID: 
To: Yoav Nir 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "" 
Subject: Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)DHE public values be fresh
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 09 Jan 2017 19:56:00 -0000

On Mon, Jan 2, 2017 at 3:57 PM, Adam Langley  wrote:
> I don't expect that those who want to intercept TLS connections will
> see a MUST NOT and go do something else. Rather I think they should
> understand that TLS isn't supposed to be intercepted and, if they want
> to do that, then they're going to be breaking the spec in places. I
> think they're going to do that no matter what we do so I want to
> ensure that these "interceptable" implementations don't inadvertently
> proliferate. (Because if everything Just Works when you accidentally
> copy such a config to your frontend server, then it'll happen.)

I had understood that the desire from some large institutions to
intercept TLS connections arose only in a datacenter setting. However,
based on private conversations, it appears that at-least one of those
institutions does this on their public frontends and will very likely
do something worse than persistent ECDHE if that's not possible with
TLS 1.3.

Thus the hope that we can detect and reject this configuration by
default, and thus prevent unintended loss of forward security, without
pushing people into implementing interception in a way that's even
worse, appears to be gone.

So I'm disappointingly now thinking that we should simply say that DH
values "SHOULD NOT" be cached for more than 10 seconds. Something like
SSLLabs can still warn when that's violated, but clients probably
cannot enforce it without perverse consequences.


Cheers

AGL

-- 
Adam Langley agl@imperialviolet.org https://www.imperialviolet.org


From nobody Mon Jan  9 15:23:12 2017
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 C4F40129980 for ; Mon,  9 Jan 2017 15:23:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.099
X-Spam-Level: 
X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 i_7odJdvmNyb for ; Mon,  9 Jan 2017 15:23:09 -0800 (PST)
Received: from excelsior.roeckx.be (excelsior.roeckx.be [195.234.45.115]) (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 DAD4E12996F for ; Mon,  9 Jan 2017 15:23:08 -0800 (PST)
Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id AA301A8A0985; Mon,  9 Jan 2017 23:23:05 +0000 (UTC)
Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 6C0AB1FE059F; Tue, 10 Jan 2017 00:23:05 +0100 (CET)
Date: Tue, 10 Jan 2017 00:23:05 +0100
From: Kurt Roeckx 
To: Adam Langley 
Message-ID: <20170109232304.pn3azqexniw3nvdu@roeckx.be>
References:     <1483330131409.25713@cs.auckland.ac.nz> <5542029D-293A-44F5-9A11-62F5C47A4BA5@gmail.com>  <071A0098-8E03-4DCB-AA3F-4AD9424C9493@gmail.com>  
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20161126 (1.7.1)
Archived-At: 
Cc: "" 
Subject: Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)DHE public values be fresh
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 09 Jan 2017 23:23:11 -0000

On Mon, Jan 09, 2017 at 02:55:57PM -0500, Adam Langley wrote:
> On Mon, Jan 2, 2017 at 3:57 PM, Adam Langley  wrote:
> > I don't expect that those who want to intercept TLS connections will
> > see a MUST NOT and go do something else. Rather I think they should
> > understand that TLS isn't supposed to be intercepted and, if they want
> > to do that, then they're going to be breaking the spec in places. I
> > think they're going to do that no matter what we do so I want to
> > ensure that these "interceptable" implementations don't inadvertently
> > proliferate. (Because if everything Just Works when you accidentally
> > copy such a config to your frontend server, then it'll happen.)
> 
> I had understood that the desire from some large institutions to
> intercept TLS connections arose only in a datacenter setting. However,
> based on private conversations, it appears that at-least one of those
> institutions does this on their public frontends and will very likely
> do something worse than persistent ECDHE if that's not possible with
> TLS 1.3.

Why can't they just decrypt it, possibly encrypt it with some
other key, and store that?


Kurt


From nobody Wed Jan 11 04:30:36 2017
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 0C27F129BCD for ; Wed, 11 Jan 2017 04:30:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.42
X-Spam-Level: 
X-Spam-Status: No, score=-7.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, 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 OSTWO_Dbk1Fy for ; Wed, 11 Jan 2017 04:30:31 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 061DA129BCC for ; Wed, 11 Jan 2017 04:30:30 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DEF79064; Wed, 11 Jan 2017 12:30:28 +0000 (GMT)
Received: from BLREML408-HUB.china.huawei.com (10.20.4.47) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 11 Jan 2017 12:30:26 +0000
Received: from BLREML509-MBX.china.huawei.com ([10.20.5.38]) by BLREML408-HUB.china.huawei.com ([10.20.4.47]) with mapi id 14.03.0301.000; Wed, 11 Jan 2017 18:00:14 +0530
From: Raja ashok 
To: "tls@ietf.org" 
Thread-Topic: New Version Notification for draft-jay-tls-psk-identity-extension-02.txt
Thread-Index: AQHSV+2GNKIWZSJWcE++ClDAq6GYuaEzW9qg
Date: Wed, 11 Jan 2017 12:30:14 +0000
Message-ID: 
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.213.121]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.58762564.0440, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: d8fe6206c3661bb5a1c5c598405cad5c
Archived-At: 
Subject: [TLS] FW: New Version Notification for draft-jay-tls-psk-identity-extension-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 11 Jan 2017 12:30:34 -0000

SGkgQWxsDQoNCkEgbmV3IGV4dGVuc2lvbiBpcyBwcm9wb3NlZCBmb3IgW0RdVExTMS4yIGFuZCBp
dHMgbG93ZXIgdmVyc2lvbihub3QgZm9yIFtEXVRMUzEuMyksIHRvIHNlbmQgUFNLSUQgaW4gY2xp
ZW50IGhlbGxvIG1zZyBpbnN0ZWFkIG9mIGNsaWVudCBrZXkgZXhjaGFuZ2UgbXNnLiBVc2luZyB0
aGlzIGV4dGVuc2lvbiwgY2xpZW50IGNhbiBzZW5kIGl0cyBsaXN0IG9mIFBTS0lEcyB0byBzZXJ2
ZXIgaW4gaXRzIGhlbGxvIG1zZyBhbmQgc2VydmVyIGNhbiBzZWxlY3QgYW55IG9uZSBvZiB0aGVt
IGFuZCByZXNwb25kIGluIGl0cyBoZWxsbyBtc2cuIA0KICAgIC0gV2l0aCB0aGUgaGVscCBvZiB0
aGlzIGV4dG4sIFBTSyBjaXBoZXIgaGFuZHNoYWtlIGNhbiBiZSBjb21wbGV0ZWQgaW4gMVJUVC4g
TWVzc2FnZXMgZXhjaGFuZ2VkIGFyZSBzaW1pbGFyIHRvIHJlc3VtcHRpb24uDQogICAgLSBGb3Ig
REhFX1BTSywgUlNBX1BTSyBhbmQgRUNESEVfUFNLIGNpcGhlcnMsIFBTS0lEIGluIGNsaWVudCBo
ZWxsbyBtc2cgZ2l2ZXMgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiB0byBzZXJ2ZXIgZm9yIGNpcGhl
ciBuZWdvdGlhdGlvbi4gSWYgdW5rbm93biBQU0tJRHMgYXJlIHByZXNlbnQsIHRoZW4gc2VydmVy
IGNhbiBzZWxlY3QgYW55IE5PTiBQU0sgY2lwaGVyIG9yIGZhaWwgYXQgdGhhdCBwbGFjZSBvbmx5
IChpbnN0ZWFkIG9mIGZhaWxpbmcgaW4gZmluaXNoZWQgbWVzc2FnZSB2ZXJpZmljYXRpb24pLg0K
DQpBbHJlYWR5IHdlIHJlY2VpdmVkIGludGVyZXN0IGFuZCByZXZpZXcgY29tbWVudHMgZnJvbSBO
aWtvcyBNYXZyb2dpYW5ub3BvdWxvcywgRGF2aWQgV29vZGhvdXNlIGFuZCBBbmRyZWFzIFdhbHou
IEJhc2VkIG9uIHRoYXQgd2UgaGF2ZSBzdWJtaXR0ZWQgdGhlIDNyZCB2ZXJzaW9uIG9mIHRoaXMg
ZG9jdW1lbnQuIA0KSSBhbSByZXF1ZXN0aW5nIG90aGVyIG1lbWJlcnMgb2YgdGhpcyBncm91cCBh
bHNvIHRvIGxvb2sgaW50byBhbmQgcHJvdmlkZSBjb21tZW50cyBmb3IgZnVydGhlciBpbXByb3Zl
bWVudHMuDQoNClJlZ2FyZHMsDQpSYWphIEFzaG9rIFYgSw0KSHVhd2VpIFRlY2hub2xvZ2llcw0K
QmFuZ2Fsb3JlLCBJbmRpYQ0KaHR0cDovL3d3dy5odWF3ZWkuY29tIA0KDQrmnKzpgq7ku7blj4rl
hbbpmYTku7blkKvmnInljY7kuLrlhazlj7jnmoTkv53lr4bkv6Hmga/vvIzku4XpmZDkuo7lj5Hp
gIHnu5nkuIrpnaLlnLDlnYDkuK3liJflh7rnmoTkuKrkurrmiJbnvqTnu4TjgILnpoENCuatouS7
u+S9leWFtuS7luS6uuS7peS7u+S9leW9ouW8j+S9v+eUqO+8iOWMheaLrOS9huS4jemZkOS6juWF
qOmDqOaIlumDqOWIhuWcsOazhOmcsuOAgeWkjeWItuOAgeaIluaVo+WPke+8ieacrOmCruS7tuS4
rQ0K55qE5L+h5oGv44CC5aaC5p6c5oKo6ZSZ5pS25LqG5pys6YKu5Lu277yM6K+35oKo56uL5Y2z
55S16K+d5oiW6YKu5Lu26YCa55+l5Y+R5Lu25Lq65bm25Yig6Zmk5pys6YKu5Lu277yBDQpUaGlz
IGUtbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0
aW9uIGZyb20gSFVBV0VJLCB3aGljaCANCmlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24g
b3IgZW50aXR5IHdob3NlIGFkZHJlc3MgaXMgbGlzdGVkIGFib3ZlLiBBbnkgdXNlIG9mIHRoZSAN
CmluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaW4gYW55IHdheSAoaW5jbHVkaW5nLCBidXQg
bm90IGxpbWl0ZWQgdG8sIHRvdGFsIG9yIHBhcnRpYWwgDQpkaXNjbG9zdXJlLCByZXByb2R1Y3Rp
b24sIG9yIGRpc3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQg
DQpyZWNpcGllbnQocykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBlLW1haWwg
aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieSANCnBob25lIG9yIGVtYWlsIGlt
bWVkaWF0ZWx5IGFuZCBkZWxldGUgaXQhDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG
cm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0
Zi5vcmddIA0KU2VudDogMTcgRGVjZW1iZXIgMjAxNiAwNDoxMQ0KVG86IFJhamEgYXNob2s7IFJh
amEgYXNob2s7IEpheWFyYWdoYXZlbmRyYW4gS3VwcGFubmFuDQpTdWJqZWN0OiBOZXcgVmVyc2lv
biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWpheS10bHMtcHNrLWlkZW50aXR5LWV4dGVuc2lvbi0w
Mi50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtamF5LXRscy1wc2staWRlbnRp
dHktZXh0ZW5zaW9uLTAyLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBS
YWphIEFzaG9rIFYgSyBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6
CQlkcmFmdC1qYXktdGxzLXBzay1pZGVudGl0eS1leHRlbnNpb24NClJldmlzaW9uOgkwMg0KVGl0
bGU6CQlUTFMvRFRMUyBQU0sgSWRlbnRpdHkgRXh0ZW5zaW9uDQpEb2N1bWVudCBkYXRlOgkyMDE2
LTEyLTE1DQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxMA0KVVJMOiAg
ICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1qYXkt
dGxzLXBzay1pZGVudGl0eS1leHRlbnNpb24tMDIudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6
Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtamF5LXRscy1wc2staWRlbnRpdHktZXh0
ZW5zaW9uLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm
dC1qYXktdGxzLXBzay1pZGVudGl0eS1leHRlbnNpb24tMDINCkRpZmY6ICAgICAgICAgICBodHRw
czovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtamF5LXRscy1wc2staWRlbnRpdHkt
ZXh0ZW5zaW9uLTAyDQoNCkFic3RyYWN0Og0KICAgUHJlLVNoYXJlZCBLZXkgKFBTSykgYmFzZWQg
S2V5IEV4Y2hhbmdlIE1lY2hhbmlzbSBpcyBwcmltYXJpbHkgdXNlZA0KICAgaW4gY29uc3RyYWlu
ZWQgZW52aXJvbm1lbnRzIHdoZXJlIHJlc291cmNlIGludGVuc2l2ZSBBc3ltbWV0cmljDQogICBD
cnlwdG9ncmFwaHkgY2Fubm90IGJlIHVzZWQuIEluIHRoZSBJbnRlcm5ldCBvZiBUaGluZ3MgKElv
VCkNCiAgIGRlcGxveW1lbnRzLCBjb25zdHJhaW5lZCBkZXZpY2VzIGFyZSBjb21tb25seSB1c2Vk
IGZvciBjb2xsZWN0aW5nDQogICBkYXRhIHZpYSBzZW5zb3JzIGZvciB1c2UgaW4gaG9tZSBhdXRv
bWF0aW9uLCBzbWFydCBlbmVyZ3kgZXRjLiBJbg0KICAgdGhpcyBjb250ZXh0LCBEVExTIGlzIGJl
aW5nIGNvbnNpZGVyZWQgYXMgdGhlIHByaW1hcnkgcHJvdG9jb2wgZm9yDQogICBjb21tdW5pY2F0
aW9uIHNlY3VyaXR5IGF0IHRoZSBhcHBsaWNhdGlvbiBsYXllciBhbmQgaW4gc29tZSBjYXNlcywg
aXQNCiAgIGlzIGFsc28gYmVpbmcgY29uc2lkZXJlZCBmb3IgbmV0d29yayBhY2Nlc3MgYXV0aGVu
dGljYXRpb24uDQoNCiAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYSBzcGVjaWZpY2F0aW9uIGZv
ciBhIG5ldyBleHRlbnNpb24gZm9yDQogICBPcHRpbWl6aW5nIERUTFMgYW5kIFRMUyBIYW5kc2hh
a2Ugd2hlbiB0aGUgUHJlLVNoYXJlZCBLZXkgKFBTSykgYmFzZWQNCiAgIEtleSBFeGNoYW5nZSBp
cyB1c2VkLiBUaGlzIGV4dGVuc2lvbiBpcyBhaW1lZCBhdCByZWR1Y2luZyB0aGUgbnVtYmVyDQog
ICBvZiBtZXNzYWdlcyBleGNoYW5nZWQgYW5kIHRoZSBSVFQgb2YgdGhlIFRMUyAmIERUTFMgSGFu
ZHNoYWtlcy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KSGksIA0KDQpJIGFtIHN1Ym1p
dHRpbmcgbXkgM3JkIHZlcnNpb24gb2Ygb3VyIGRyYWZ0KGRyYWZ0LWpheS10bHMtcHNrLWlkZW50
aXR5LWV4dGVuc2lvbikgaW4gVExTIHdvcmtpbmcgZ3JvdXAuIA0KDQpQbGVhc2Ugbm90ZSB0aGF0
IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNz
aW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQg
dG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg==


From nobody Wed Jan 11 15:32:42 2017
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 6C2AC129542; Wed, 11 Jan 2017 15:32:40 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.40.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148417756044.8147.15207968448003070200.idtracker@ietfa.amsl.com>
Date: Wed, 11 Jan 2017 15:32:40 -0800
Archived-At: 
Cc: tls@ietf.org
Subject: [TLS] I-D Action: draft-ietf-tls-dnssec-chain-extension-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 11 Jan 2017 23:32:40 -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 of the IETF.

        Title           : A DANE Record and DNSSEC Authentication Chain Extension for TLS
        Authors         : Melinda Shore
                          Richard Barnes
                          Shumon Huque
                          Willem Toorop
	Filename        : draft-ietf-tls-dnssec-chain-extension-02.txt
	Pages           : 14
	Date            : 2017-01-11

Abstract:
   This draft describes a new TLS extension for transport of a DNS
   record set serialized with the DNSSEC signatures needed to
   authenticate that record set.  The intent of this proposal is to
   allow TLS clients to perform DANE authentication of a TLS server
   certificate without needing to perform additional DNS record lookups.
   It will typically not be used for general DNSSEC validation of TLS
   endpoint names.


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-tls-dnssec-chain-extension-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dnssec-chain-extension-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 Wed Jan 11 16:17:18 2017
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 AB94A1295D1 for ; Wed, 11 Jan 2017 16:17:16 -0800 (PST)
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 qpLII_FL6za1 for ; Wed, 11 Jan 2017 16:17:15 -0800 (PST)
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 9F5CD129542 for ; Wed, 11 Jan 2017 16:17:15 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 8B66C1E565A; Wed, 11 Jan 2017 16:17:00 -0800 (PST)
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 RcTRBxHPJs7e; Wed, 11 Jan 2017 16:16:59 -0800 (PST)
Received: from [192.168.20.3] (unknown [121.98.247.46]) by c8a.amsl.com (Postfix) with ESMTPSA id 58AFF1E5656; Wed, 11 Jan 2017 16:16:59 -0800 (PST)
To: tls@ietf.org
From: Nevil Brownlee 
Organization: Independent Stream
Message-ID: <9a4163c6-4908-c79a-8112-075c34c8dd9a@rfc-editor.org>
Date: Thu, 12 Jan 2017 13:17:12 +1300
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: ISE 
Subject: [TLS] ISE needs reviewer(s) for draft-harkins-tls-dragonfly
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 12 Jan 2017 00:17:17 -0000

Hi TLS experts:

Dan Harkins has submitted this draft to the Independent Stream.  I already
have one review for it, but I need one or two more.  Please could anyone
on this (TLS) list please take a look at it, and send me their comments?

Cheers, Nevil  (Independent Submissions Editor)

-- 
Nevil Brownlee (ISE), rfc-ise@rfc-editor.org


From nobody Wed Jan 11 22:02:39 2017
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 BDB9B129479; Wed, 11 Jan 2017 22:02:38 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.40.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148420095877.8269.18377782868390849372.idtracker@ietfa.amsl.com>
Date: Wed, 11 Jan 2017 22:02:38 -0800
Archived-At: 
Cc: tls@ietf.org
Subject: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-10.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 12 Jan 2017 06:02:39 -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 of the IETF.

        Title           : Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier
        Authors         : Yoav Nir
                          Simon Josefsson
                          Manuel Pegourie-Gonnard
	Filename        : draft-ietf-tls-rfc4492bis-10.txt
	Pages           : 32
	Date            : 2017-01-11

Abstract:
   This document describes key exchange algorithms based on Elliptic
   Curve Cryptography (ECC) for the Transport Layer Security (TLS)
   protocol.  In particular, it specifies the use of Ephemeral Elliptic
   Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the
   use of Elliptic Curve Digital Signature Algorithm (ECDSA) and Edwards
   Digital Signature Algorithm (EdDSA) as authentication mechanisms.


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-rfc4492bis-10


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 Jan 11 22:13:11 2017
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 4DB7812948E; Wed, 11 Jan 2017 22:13:10 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.40.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148420159031.8175.9142724600491868931.idtracker@ietfa.amsl.com>
Date: Wed, 11 Jan 2017 22:13:10 -0800
Archived-At: 
Cc: tls@ietf.org
Subject: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-11.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 12 Jan 2017 06:13:10 -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 of the IETF.

        Title           : Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier
        Authors         : Yoav Nir
                          Simon Josefsson
                          Manuel Pegourie-Gonnard
	Filename        : draft-ietf-tls-rfc4492bis-11.txt
	Pages           : 32
	Date            : 2017-01-11

Abstract:
   This document describes key exchange algorithms based on Elliptic
   Curve Cryptography (ECC) for the Transport Layer Security (TLS)
   protocol.  In particular, it specifies the use of Ephemeral Elliptic
   Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the
   use of Elliptic Curve Digital Signature Algorithm (ECDSA) and Edwards
   Digital Signature Algorithm (EdDSA) as authentication mechanisms.


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-rfc4492bis-11


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 Jan 12 07:27:52 2017
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 3916E129887 for ; Thu, 12 Jan 2017 07:27:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.198
X-Spam-Level: 
X-Spam-Status: No, score=-5.198 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, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-offenburg.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 2xvrH_3_uL84 for ; Thu, 12 Jan 2017 07:27:47 -0800 (PST)
Received: from mx.hs-offenburg.de (mx.hs-offenburg.de [141.79.11.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ECA9129886 for ; Thu, 12 Jan 2017 07:27:44 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx.hs-offenburg.de (Postfix) with ESMTP id B7F851636A29 for ; Thu, 12 Jan 2017 16:27:42 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-offenburg.de; h=content-type:content-type:mime-version:in-reply-to:references :subject:subject:from:from:date:date:x-mailer:message-id :received:received:received; s=default; t=1484234861; x= 1485098862; bh=xA+2lmL2Vwsp2sK+eS8n9mF7etixf774864m4KmdFUc=; b=A dyQ8Q+UrIn8Q9k1Dza85kUtPQgHKK1YoSa+yBmxVwRJ/Lfy0x/CHNN40T2vGYKLb +Qzf95E9hLCbUXpGp51tSO/SWZij6JkkvvU73esjmRv6dGvaJEXo12+FRaCYwKa8 PiNijlHGUau17Iy82zLqWS6g8dhZf6orcpbOXIF7fU=
X-Virus-Scanned: amavisd-new at hs-offenburg.de
Received: from mx.hs-offenburg.de ([127.0.0.1]) by localhost (mx.hs-offenburg.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNwq-jW_5q2S for ; Thu, 12 Jan 2017 16:27:41 +0100 (CET)
Received: from gwia2.rz.hs-offenburg.de (gwia2.rz.hs-offenburg.de [141.79.10.30]) by mx.hs-offenburg.de (Postfix) with ESMTPS id ECECA1636A1A for ; Thu, 12 Jan 2017 16:27:40 +0100 (CET)
Received: from gw_dom-gwia2-MTA by gwia2.rz.hs-offenburg.de with Novell_GroupWise; Thu, 12 Jan 2017 16:27:40 +0100
Message-Id: <5877AE7B020000AC00125968@gwia2.rz.hs-offenburg.de>
X-Mailer: Novell GroupWise Internet Agent 14.2.1 
Date: Thu, 12 Jan 2017 16:27:39 +0100
From: "Andreas Walz" 
To: ,
References: 
In-Reply-To: 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part9CA5BE7B.2__="
Archived-At: 
Subject: Re: [TLS] FW: New Version Notification for draft-jay-tls-psk-identity-extension-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 12 Jan 2017 15:27:50 -0000

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part9CA5BE7B.2__=
Content-Type: multipart/alternative; boundary="=__Part9CA5BE7B.3__="

--=__Part9CA5BE7B.3__=
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Dear all,

I read through the draft and I do have some questions/comments which you
can find below:

-> Section 1, 2nd paragraph: Maybe one could mention explicitly that the
new extension allows to do during the Hello phase what would otherwise
be done in separate messages in a separate round trip.
-> Section 3, 2nd paragraph, under a): it is written "...it checks
whether it supports PSK based authentication for its client.". What does
"its client" refer to? This is supposed to refer to the ordinary PSK
handshake where the server only knows the client's network address at
this point in time, isn’t it?
-> Section 5.2, 1st paragraph: "Clients supporting this extension should
include ...". Is there a reason you don't use "SHOULD"?
-> Section 5.2: There is no statement about the order of PSK identities
in the extension. Does it mean the order is of no relevance at all? Why
not allowing the client to express its preferences by means of ordering
the items in the list?
-> Section 5.3: The fact that abbreviating the handshake only works for
pure PSK cipher suites is only mentioned in the third paragraph. Maybe
this can be made more explicit somewhere at the beginning of this
section (e.g. changing the heading to "Abbreviated Handshake for pure
PSK Cipher Suites" or the like)?
-> Section 5.3, 4th paragraph: the last paragraph only states that for
DHE_PSK, RSA_PSK, ECDHE_PSK the server and client key exchange messages
are still required. It doesn't say anything about whether the presence
of the new extension changes the format of these messages. I would
expect that server and client key exchange messages omit the PSK_ID part
then…or do they keep that part? What is the content then? This should be
mentioned somehow, maybe as a separate section?
-> Section 5.3: What is a server (client) expected to do if it receives
a client (server) key exchange message during an abbreviated handshake
(with pure PSK cipher suites)? Maybe mention "During an abbreviated
handshake the server MUST NOT send a server key exchange message and the
client MUST NOT send a client key exchange message. Otherwise the
receiver MUST abort the handshake with an unexpected_message alert."

Some minor comments/typos:

-> "PSK" and "pre-shared key" is used alternately in the draft
-> Section 2, 2nd paragraph: "Incase" -> "In case"
-> Section 5.2, 2nd paragraph: "Please note that, Server MUST include
this extension ...". I would change this to "Servers MUST NOT send this
extension unless the client sent it in the client hello."
-> Section 5.3: A "(" is missing in the diagram below "ServerHello"
-> There are some more typos. Do you have a Git repository where I could
post a pull request for those? I guess that would be more efficient than
listing them here.

Thanks and Cheers,
Andi Walz

___________________________________

Andreas Walz
Research Engineer
Institute of reliable Embedded Systems and Communication Electronics
(ivESK)
Offenburg University of Applied Sciences, 77652 Offenburg, Germany






>>> Raja ashok  01/11/17 1:31 PM >>>
Hi All

A new extension is proposed for [D]TLS1.2 and its lower version(not for
[D]TLS1.3), to send PSKID in client hello msg instead of client key
exchange msg. Using this extension, client can send its list of PSKIDs
to server in its hello msg and server can select any one of them and
respond in its hello msg. 
    - With the help of this extn, PSK cipher handshake can be completed
in 1RTT. Messages exchanged are similar to resumption.
    - For DHE_PSK, RSA_PSK and ECDHE_PSK ciphers, PSKID in client hello
msg gives additional information to server for cipher negotiation. If
unknown PSKIDs are present, then server can select any NON PSK cipher or
fail at that place only (instead of failing in finished message
verification).

Already we received interest and review comments from Nikos
Mavrogiannopoulos, David Woodhouse and Andreas Walz. Based on that we
have submitted the 3rd version of this document. 
I am requesting otheprovide comments for further improvements.

Regards,
Raja Ashok V K
Huawei Technologies
Bangalore, India
http://www.huawei.com 

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from
HUAWEI, which 
is intended only for the person or entity whose address is listed above.
Any use of the 
information contained herein in any way (including, but not limited to,
total or partial 
disclosure, reproduction, or dissemination) by persons other than the
intended 
recipient(s) is prohibited. If you receive this e-mail in error, please
notify the sender by 
phone or email immediately and delete it!

-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
Sent: 17 December 2016 04:11
To: Raja ashok; Raja ashok; Jayaraghavendran Kuppannan
Subject: New Version Notification for
draft-jay-tls-psk-identity-extension-02.txt


A new version of I-D, draft-jay-tls-psk-identity-extension-02.txt
has been successfully submitted by Raja Ashok V K and posted to the IETF
repository.

Name:        draft-jay-tls-psk-identity-extension
Revision:    02
Title:        TLS/DTLS PSK Identity Extension
Document date:    2016-12-15
Group:        Individual Submission
Pages:        10
URL:           
https://www.ietf.org/internet-drafts/draft-jay-tls-psk-identity-extension-02.txt
Status:        
https://datatracker.ietf.org/doc/draft-jay-tls-psk-identity-extension/
Htmlized:      
https://tools.ietf.org/html/draft-jay-tls-psk-identity-extension-02
Diff:          
https://www.ietf.org/rfcdiff?url2=draft-jay-tls-psk-identity-extension-02

Abstract:
   Pre-Shared Key (PSK) based Key Exchange Mechanism is primarily used
   in constrained environments where resource intensive Asymmetric
   Cryptography cannot be used. In the Internet of Things (IoT)
   deployments, constrained devices are commonly used for collecting
   data via sensors for use in home automation, smart energy etc. In
   this context, DTLS is being considered as the primary protocol for
   communication security at the application layer and in some cases, it
   is also being considered for network access authentication.

   This document provides a specification for a new extension for
   Optimizing DTLS and TLS Handshake when the Pre-Shared Key (PSK) based
   Key Exchange is used. This extension is aimed at reducing the number
   of messages exchanged and the RTT of the TLS & DTLS Handshakes.

                                                                        
         
Hi, 

I am submitting my 3rd version of our
draft(draft-jay-tls-psk-identity-extension) in TLS working group. 

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

The IETF Secretariat

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



--=__Part9CA5BE7B.3__=
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
Content-Description: HTML

 =0Abody p =0A{ =0A	margin: 0px; =0A}=0A
Dear all,

I read through the draft and I do have some =
questions/comments which you can find below:

-> Section 1, 2nd =
paragraph: Maybe one could mention explicitly that the new extension =
allows to do during the Hello phase what would otherwise be done in =
separate messages in a separate round trip.
-> Section 3, 2nd =
paragraph, under a): it is written "...it checks whether it supports PSK =
based authentication for its client.". What does "its client" refer to? =
This is supposed to refer to the ordinary PSK handshake where the server =
only knows the client's network address at this point in time, isn=E2=80=99=
t it?
-> Section 5.2, 1st paragraph: "Clients supporting this =
extension should include ...". Is there a reason you don't use "SHOULD"?-> Section 5.2: There is no statement about the order of PSK identities=
 in the extension. Does it mean the order is of no relevance at all? Why =
not allowing the client to express its preferences by means of ordering =
the items in the list?
-> Section 5.3: The fact that abbreviating =
the handshake only works for pure PSK cipher suites is only mentioned in =
the third paragraph. Maybe this can be made more explicit somewhere at the =
beginning of this section (e.g. changing the heading to "Abbreviated =
Handshake for pure PSK Cipher Suites" or the like)?
-> Section 5.3, =
4th paragraph: the last paragraph only states that for DHE_PSK, RSA_PSK, =
ECDHE_PSK the server and client key exchange messages are still required. =
It doesn't say anything about whether the presence of the new extension =
changes the format of these messages. I would expect that server and =
client key exchange messages omit the PSK_ID part then=E2=80=A6or do they =
keep that part? What is the content then? This should be mentioned =
somehow, maybe as a separate section?
-> Section 5.3: What is a =
server (client) expected to do if it receives a client (server) key =
exchange message during an abbreviated handshake (with pure PSK cipher =
suites)? Maybe mention "During an abbreviated handshake the server MUST =
NOT send a server key exchange message and the client MUST NOT send a =
client key exchange message. Otherwise the receiver MUST abort the =
handshake with an unexpected_message alert."

Some minor comments/typ=
os:

-> "PSK" and "pre-shared key" is used alternately in the =
draft
-> Section 2, 2nd paragraph: "Incase" -> "In case"
-> =
Section 5.2, 2nd paragraph: "Please note that, Server MUST include this =
extension ...". I would change this to "Servers MUST NOT send this =
extension unless the client sent it in the client hello."
-> Section =
5.3: A "(" is missing in the diagram below "ServerHello"
-> There =
are some more typos. Do you have a Git repository where I could post a =
pull request for those? I guess that would be more efficient than listing =
them here.

Thanks and Cheers,
Andi Walz

__________________=
_________________

Andreas Walz
Research Engineer
Institute of =
reliable Embedded Systems and Communication Electronics (ivESK)
Offenbur=
g University of Applied Sciences, 77652 Offenburg, Germany


 

>>&g=
t; Raja ashok <raja.ashok@huawei.com> 01/11/17 1:31 PM =
>>>
Hi All

A new extension is proposed for =
[D]TLS1.2 and its lower version(not for [D]TLS1.3), to send PSKID in =
client hello msg instead of client key exchange msg. Using this extension, =
client can send its list of PSKIDs to server in its hello msg and server =
can select any one of them and respond in its hello msg. 
    - With =
the help of this extn, PSK cipher handshake can be completed in 1RTT. =
Messages exchanged are similar to resumption.
    - For DHE_PSK, =
RSA_PSK and ECDHE_PSK ciphers, PSKID in client hello msg gives additional =
information to server for cipher negotiation. If unknown PSKIDs are =
present, then server can select any NON PSK cipher or fail at that place =
only (instead of failing in finished message verification).

Already =
we received interest and review comments from Nikos Mavrogiannopoulos, =
David Woodhouse and Andreas Walz. Based on that we have submitted the 3rd =
version of this document. 
I am requesting other members of this group =
also to look into and provide comments for further improvements.

Reg=
ards,
Raja Ashok V K
Huawei Technologies
Bangalore, India
http:=
//www.huawei.com 

=E6=9C=AC=E9=82=AE=E4=BB=B6=E5=8F=8A=E5=85=B6=E9=
=99=84=E4=BB=B6=E5=90=AB=E6=9C=89=E5=8D=8E=E4=B8=BA=E5=85=AC=E5=8F=B8=E7=9A=
=84=E4=BF=9D=E5=AF=86=E4=BF=A1=E6=81=AF=EF=BC=8C=E4=BB=85=E9=99=90=E4=BA=8E=
=E5=8F=91=E9=80=81=E7=BB=99=E4=B8=8A=E9=9D=A2=E5=9C=B0=E5=9D=80=E4=B8=AD=E5=
=88=97=E5=87=BA=E7=9A=84=E4=B8=AA=E4=BA=BA=E6=88=96=E7=BE=A4=E7=BB=84=E3=80=
=82=E7=A6=81
=E6=AD=A2=E4=BB=BB=E4=BD=95=E5=85=B6=E4=BB=96=E4=BA=BA=E4=
=BB=A5=E4=BB=BB=E4=BD=95=E5=BD=A2=E5=BC=8F=E4=BD=BF=E7=94=A8=EF=BC=88=E5=8C=
=85=E6=8B=AC=E4=BD=86=E4=B8=8D=E9=99=90=E4=BA=8E=E5=85=A8=E9=83=A8=E6=88=96=
=E9=83=A8=E5=88=86=E5=9C=B0=E6=B3=84=E9=9C=B2=E3=80=81=E5=A4=8D=E5=88=B6=E3=
=80=81=E6=88=96=E6=95=A3=E5=8F=91=EF=BC=89=E6=9C=AC=E9=82=AE=E4=BB=B6=E4=B8=
=AD
=E7=9A=84=E4=BF=A1=E6=81=AF=E3=80=82=E5=A6=82=E6=9E=9C=E6=82=A8=E9=
=94=99=E6=94=B6=E4=BA=86=E6=9C=AC=E9=82=AE=E4=BB=B6=EF=BC=8C=E8=AF=B7=E6=82=
=A8=E7=AB=8B=E5=8D=B3=E7=94=B5=E8=AF=9D=E6=88=96=E9=82=AE=E4=BB=B6=E9=80=9A=
=E7=9F=A5=E5=8F=91=E4=BB=B6=E4=BA=BA=E5=B9=B6=E5=88=A0=E9=99=A4=E6=9C=AC=E9=
=82=AE=E4=BB=B6=EF=BC=81
This e-mail and its attachments contain =
confidential information from HUAWEI, which 
is intended only for the =
person or entity whose address is listed above. Any use of the 
informat=
ion contained herein in any way (including, but not limited to, total or =
partial 
disclosure, reproduction, or dissemination) by persons other =
than the intended 
recipient(s) is prohibited. If you receive this =
e-mail in error, please notify the sender by 
phone or email immediately=
 and delete it!

-----Original Message-----
From: internet-drafts@=
ietf.org [mailto:internet-drafts@ietf.org] 
Sent: 17 December 2016 =
04:11
To: Raja ashok; Raja ashok; Jayaraghavendran Kuppannan
Subject:=
 New Version Notification for draft-jay-tls-psk-identity-extension-02.txt

A new version of I-D, draft-jay-tls-psk-identity-extension-02.txt=

has been successfully submitted by Raja Ashok V K and posted to the =
IETF repository.

Name:       &nbs=
p;draft-jay-tls-psk-identity-extension
Revision:    =
02
Title:        TLS/DTLS PSK =
Identity Extension
Document date:    2016-12-15
G=
roup:        Individual Submission<=
br>Pages:        10
URL:        =
    https://www.ietf.org/internet-drafts/draft-jay-tls-psk-identity-extensi=
on-02.txt
Status:         https://datatracker.ietf.org/doc/draft-jay-tls=
-psk-identity-extension/
Htmlized:       https://tools.ietf.org/html/dra=
ft-jay-tls-psk-identity-extension-02
Diff:           https://www.ietf.or=
g/rfcdiff?url2=3Ddraft-jay-tls-psk-identity-extension-02

Abstract:   Pre-Shared Key (PSK) based Key Exchange Mechanism is primarily =
used
   in constrained environments where resource intensive Asymmetric<=
br>   Cryptography cannot be used. In the Internet of Things (IoT)
   =
deployments, constrained devices are commonly used for collecting
   =
data via sensors for use in home automation, smart energy etc. In
   =
this context, DTLS is being considered as the primary protocol for
   =
communication security at the application layer and in some cases, it
  =
 is also being considered for network access authentication.

   =
This document provides a specification for a new extension for
   =
Optimizing DTLS and TLS Handshake when the Pre-Shared Key (PSK) based
  =
 Key Exchange is used. This extension is aimed at reducing the number
  =
 of messages exchanged and the RTT of the TLS & DTLS Handshakes.
                                                                          =
        
Hi, 

I am submitting my 3rd version of our draft(draft-j=
ay-tls-psk-identity-extension) in TLS working group. 

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

The IETF =
Secretariat

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


--=__Part9CA5BE7B.3__=--

--=__Part9CA5BE7B.2__=--


From nobody Fri Jan 13 01:27:32 2017
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 6B8CC129B38 for ; Fri, 13 Jan 2017 01:27:31 -0800 (PST)
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 naUhoLjrws6J for ; Fri, 13 Jan 2017 01:27:28 -0800 (PST)
Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (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 7B09A129AB1 for ; Fri, 13 Jan 2017 01:27:21 -0800 (PST)
Received: by mail-ua0-x22f.google.com with SMTP id 35so33013886uak.1 for ; Fri, 13 Jan 2017 01:27:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AivPTXxUTKqAlnVgrZy+UXY1+8efgJWpSrKMJfyenKg=; b=HzJRuIU6x2H//mXG8aDliqykldAgOuWMyVjqNaaOpBUvEnnFrV0Gt8A9M8NdB/eoXp 3hHf7IPUwINXDaYTvn9YzrXjG+Py9UVTZ8JRKiizHcGSiQ1PAHLzbmY2y/llaxEXI0v9 wAQFJVE9/IU5/CMZ79NrfVkG8aMOs01pmKxedrLTy3UOyNuGZYVUbJ/pQg2ILylkcAF7 1gfLFzlRH0pUSmBbrgzE/K4GdYJY/hhY/f1jfb4vXr0tJplZYUC2FxYwHqNXuMzAjaoU J9Sx1ZokIy+v30osgmwc3YkU1PwwbU48B7LTDOlf6etaho/mbkOQDSor+pBbEsIRFQp5 XECg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AivPTXxUTKqAlnVgrZy+UXY1+8efgJWpSrKMJfyenKg=; b=uBHwKu1JeKNpaLYjKE/JqppDs4Q8wJCCIRCYY+pkzDAlclr1fV+FlydPZPhlnoz5XH lnLrp325EhDB7d/M4SDjUsKLAssTTj7xMD0TnH7YPpE2Qdyt0ybm4fv6/sMjI4jFs5Mz 5CIUqX3BTDqgTM0hrZ/u2II/792NHvZtoBawBv8YkGapro7XZBSN0KN4w3ggmAPUY3Ho gC6CWze/T6qtFaMc7ae369qj/iJL7ccsI/7a8QrRn1bGSL+3flg2W8gz3OiQl9yGaYcS su2W0A7VX0uwfC+qKuQ6nas1io2DtG07irfEdyF7Pebnr3kRb1uGj5wywlK+MXapmtIb PA2w==
X-Gm-Message-State: AIkVDXLyNMbEqUOu0/omV36DlAxJAzmkVXbD08RqKJY8tmAyHJSEVIX5jeT/liJBW03AgyU2I2NvqEU8TkIuBA==
X-Received: by 10.176.67.1 with SMTP id k1mr8484557uak.125.1484299640479; Fri, 13 Jan 2017 01:27:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.28.70 with HTTP; Fri, 13 Jan 2017 01:27:20 -0800 (PST)
In-Reply-To: <5877AE7B020000AC00125968@gwia2.rz.hs-offenburg.de>
References:  <5877AE7B020000AC00125968@gwia2.rz.hs-offenburg.de>
From: Jayaraghavendran Kuppannan 
Date: Fri, 13 Jan 2017 14:57:20 +0530
Message-ID: 
To: Andreas Walz 
Content-Type: multipart/alternative; boundary=001a114b5b48cfa5ce0545f67038
Archived-At: 
Cc: tls@ietf.org
Subject: Re: [TLS] FW: New Version Notification for draft-jay-tls-psk-identity-extension-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 13 Jan 2017 09:27:31 -0000

--001a114b5b48cfa5ce0545f67038
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Andi,

Thanks a lot for your comments. We will be fixing them.

Right now, we don't have the Git Repository for this draft. Will set it up
shortly (within a day or two) and send you the link for the updates related
to the typos.

Also, it would be great, if you could elaborate on your scenario, so that
we can add parts of it in our draft as a part of the use cases.


Regards,
Jay



On Thu, Jan 12, 2017 at 8:57 PM, Andreas Walz 
wrote:

> Dear all,
>
> I read through the draft and I do have some questions/comments which you
> can find below:
>
> -> Section 1, 2nd paragraph: Maybe one could mention explicitly that the
> new extension allows to do during the Hello phase what would otherwise be
> done in separate messages in a separate round trip.
> -> Section 3, 2nd paragraph, under a): it is written "...it checks whethe=
r
> it supports PSK based authentication for its client.". What does "its
> client" refer to? This is supposed to refer to the ordinary PSK handshake
> where the server only knows the client's network address at this point in
> time, isn=E2=80=99t it?
> -> Section 5.2, 1st paragraph: "Clients supporting this extension should
> include ...". Is there a reason you don't use "SHOULD"?
> -> Section 5.2: There is no statement about the order of PSK identities i=
n
> the extension. Does it mean the order is of no relevance at all? Why not
> allowing the client to express its preferences by means of ordering the
> items in the list?
> -> Section 5.3: The fact that abbreviating the handshake only works for
> pure PSK cipher suites is only mentioned in the third paragraph. Maybe th=
is
> can be made more explicit somewhere at the beginning of this section (e.g=
.
> changing the heading to "Abbreviated Handshake for pure PSK Cipher Suites=
"
> or the like)?
> -> Section 5.3, 4th paragraph: the last paragraph only states that for
> DHE_PSK, RSA_PSK, ECDHE_PSK the server and client key exchange messages a=
re
> still required. It doesn't say anything about whether the presence of the
> new extension changes the format of these messages. I would expect that
> server and client key exchange messages omit the PSK_ID part then=E2=80=
=A6or do
> they keep that part? What is the content then? This should be mentioned
> somehow, maybe as a separate section?
> -> Section 5.3: What is a server (client) expected to do if it receives a
> client (server) key exchange message during an abbreviated handshake (wit=
h
> pure PSK cipher suites)? Maybe mention "During an abbreviated handshake t=
he
> server MUST NOT send a server key exchange message and the client MUST NO=
T
> send a client key exchange message. Otherwise the receiver MUST abort the
> handshake with an unexpected_message alert."
>
> Some minor comments/typos:
>
> -> "PSK" and "pre-shared key" is used alternately in the draft
> -> Section 2, 2nd paragraph: "Incase" -> "In case"
> -> Section 5.2, 2nd paragraph: "Please note that, Server MUST include thi=
s
> extension ...". I would change this to "Servers MUST NOT send this
> extension unless the client sent it in the client hello."
> -> Section 5.3: A "(" is missing in the diagram below "ServerHello"
> -> There are some more typos. Do you have a Git repository where I could
> post a pull request for those? I guess that would be more efficient than
> listing them here.
>
> Thanks and Cheers,
> Andi Walz
>
> ___________________________________
>
> Andreas Walz
> Research Engineer
> Institute of reliable Embedded Systems and Communication Electronics
> (ivESK)
> Offenburg University of Applied Sciences, 77652 Offenburg, Germany
>
>
>
>
> >>> Raja ashok  01/11/17 1:31 PM >>>
> Hi All
>
> A new extension is proposed for [D]TLS1.2 and its lower version(not for
> [D]TLS1.3), to send PSKID in client hello msg instead of client key
> exchange msg. Using this extension, client can send its list of PSKIDs to
> server in its hello msg and server can select any one of them and respond
> in its hello msg.
> - With the help of this extn, PSK cipher handshake can be completed in
> 1RTT. Messages exchanged are similar to resumption.
> - For DHE_PSK, RSA_PSK and ECDHE_PSK ciphers, PSKID in client hello msg
> gives additional information to server for cipher negotiation. If unknown
> PSKIDs are present, then server can select any NON PSK cipher or fail at
> that place only (instead of failing in finished message verification).
>
> Already we received interest and review comments from Nikos
> Mavrogiannopoulos, David Woodhouse and Andreas Walz. Based on that we hav=
e
> submitted the 3rd version of this document.
> I am requesting other members of this group also to look into and provide
> comments for further improvements.
>
> Regards,
> Raja Ashok V K
> Huawei Technologies
> Bangalore, India
> http://www.huawei.com
>
> =E6=9C=AC=E9=82=AE=E4=BB=B6=E5=8F=8A=E5=85=B6=E9=99=84=E4=BB=B6=E5=90=AB=
=E6=9C=89=E5=8D=8E=E4=B8=BA=E5=85=AC=E5=8F=B8=E7=9A=84=E4=BF=9D=E5=AF=86=E4=
=BF=A1=E6=81=AF=EF=BC=8C=E4=BB=85=E9=99=90=E4=BA=8E=E5=8F=91=E9=80=81=E7=BB=
=99=E4=B8=8A=E9=9D=A2=E5=9C=B0=E5=9D=80=E4=B8=AD=E5=88=97=E5=87=BA=E7=9A=84=
=E4=B8=AA=E4=BA=BA=E6=88=96=E7=BE=A4=E7=BB=84=E3=80=82=E7=A6=81
> =E6=AD=A2=E4=BB=BB=E4=BD=95=E5=85=B6=E4=BB=96=E4=BA=BA=E4=BB=A5=E4=BB=BB=
=E4=BD=95=E5=BD=A2=E5=BC=8F=E4=BD=BF=E7=94=A8=EF=BC=88=E5=8C=85=E6=8B=AC=E4=
=BD=86=E4=B8=8D=E9=99=90=E4=BA=8E=E5=85=A8=E9=83=A8=E6=88=96=E9=83=A8=E5=88=
=86=E5=9C=B0=E6=B3=84=E9=9C=B2=E3=80=81=E5=A4=8D=E5=88=B6=E3=80=81=E6=88=96=
=E6=95=A3=E5=8F=91=EF=BC=89=E6=9C=AC=E9=82=AE=E4=BB=B6=E4=B8=AD
> =E7=9A=84=E4=BF=A1=E6=81=AF=E3=80=82=E5=A6=82=E6=9E=9C=E6=82=A8=E9=94=99=
=E6=94=B6=E4=BA=86=E6=9C=AC=E9=82=AE=E4=BB=B6=EF=BC=8C=E8=AF=B7=E6=82=A8=E7=
=AB=8B=E5=8D=B3=E7=94=B5=E8=AF=9D=E6=88=96=E9=82=AE=E4=BB=B6=E9=80=9A=E7=9F=
=A5=E5=8F=91=E4=BB=B6=E4=BA=BA=E5=B9=B6=E5=88=A0=E9=99=A4=E6=9C=AC=E9=82=AE=
=E4=BB=B6=EF=BC=81
> This e-mail and its attachments contain confidential information from
> HUAWEI, which
> is intended only for the person or entity whose address is listed above.
> Any use of the
> information contained herein in any way (including, but not limited to,
> total or partial
> disclosure, reproduction, or dissemination) by persons other than the
> intended
> recipient(s) is prohibited. If you receive this e-mail in error, please
> notify the sender by
> phone or email immediately and delete it!
>
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> Sent: 17 December 2016 04:11
> To: Raja ashok; Raja ashok; Jayaraghavendran Kuppannan
> Subject: New Version Notification for draft-jay-tls-psk-identity-
> extension-02.txt
>
>
> A new version of I-D, draft-jay-tls-psk-identity-extension-02.txt
> has been successfully submitted by Raja Ashok V K and posted to the IETF
> repository.
>
> Name:        draft-jay-tls-psk-identity-extension
> Revision:    02
> Title:        TLS/DTLS PSK Identity Extension
> Document date:    2016-12-15
> Group:        Individual Submission
> Pages:        10
> URL: https://www.ietf.org/internet-drafts/draft-jay-tls-psk-
> identity-extension-02.txt
> Status: https://datatracker.ietf.org/doc/draft-jay-tls-psk-
> identity-extension/
> Htmlized: https://tools.ietf.org/html/draft-jay-tls-psk-identity-
> extension-02
> Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-jay-tls-psk-
> identity-extension-02
>
> Abstract:
> Pre-Shared Key (PSK) based Key Exchange Mechanism is primarily used
> in constrained environments where resource intensive Asymmetric
> Cryptography cannot be used. In the Internet of Things (IoT)
> deployments, constrained devices are commonly used for collecting
> data via sensors for use in home automation, smart energy etc. In
> this context, DTLS is being considered as the primary protocol for
> communication security at the application layer and in some cases, it
> is also being considered for network access authentication.
>
> This document provides a specification for a new extension for
> Optimizing DTLS and TLS Handshake when the Pre-Shared Key (PSK) based
> Key Exchange is used. This extension is aimed at reducing the number
> of messages exchanged and the RTT of the TLS & DTLS Handshakes.
>
>
> Hi,
>
> I am submitting my 3rd version of our draft(draft-jay-tls-psk-identity-ex=
tension)
> in TLS working group.
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> The IETF Secretariat
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--001a114b5b48cfa5ce0545f67038
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Andi,

Thanks a lot for your comments=
. We will be fixing them.

Right now, we don't =
have the Git Repository for this draft. Will set it up shortly (within a da=
y or two) and send you the link for the updates related to the typos.
=


Also, it would be great, if you could elaborate on your=
 scenario, so that we can add parts of it in our draft as a part of the use=
 cases.=C2=A0


Regards,
Ja=
y



<=
div class=3D"gmail_quote">On Thu, Jan 12, 2017 at 8:57 PM, Andreas Walz <andreas.walz@hs-offenburg.de> wrote:
Dear all,

I read=
 through the draft and I do have some questions/comments which you can find=
 below:

-> Section 1, 2nd paragraph: Maybe one could mention expl=
icitly that the new extension allows to do during the Hello phase what woul=
d otherwise be done in separate messages in a separate round trip.
->=
 Section 3, 2nd paragraph, under a): it is written "...it checks wheth=
er it supports PSK based authentication for its client.". What does &q=
uot;its client" refer to? This is supposed to refer to the ordinary PS=
K handshake where the server only knows the client's network address at=
 this point in time, isn=E2=80=99t it?
-> Section 5.2, 1st paragraph:=
 "Clients supporting this extension should include ...". Is there=
 a reason you don't use "SHOULD"?
-> Section 5.2: There=
 is no statement about the order of PSK identities in the extension. Does i=
t mean the order is of no relevance at all? Why not allowing the client to =
express its preferences by means of ordering the items in the list?
->=
; Section 5.3: The fact that abbreviating the handshake only works for pure=
 PSK cipher suites is only mentioned in the third paragraph. Maybe this can=
 be made more explicit somewhere at the beginning of this section (e.g. cha=
nging the heading to "Abbreviated Handshake for pure PSK Cipher Suites=
" or the like)?
-> Section 5.3, 4th paragraph: the last paragrap=
h only states that for DHE_PSK, RSA_PSK, ECDHE_PSK the server and client ke=
y exchange messages are still required. It doesn't say anything about w=
hether the presence of the new extension changes the format of these messag=
es. I would expect that server and client key exchange messages omit the PS=
K_ID part then=E2=80=A6or do they keep that part? What is the content then?=
 This should be mentioned somehow, maybe as a separate section?
-> Se=
ction 5.3: What is a server (client) expected to do if it receives a client=
 (server) key exchange message during an abbreviated handshake (with pure P=
SK cipher suites)? Maybe mention "During an abbreviated handshake the =
server MUST NOT send a server key exchange message and the client MUST NOT =
send a client key exchange message. Otherwise the receiver MUST abort the h=
andshake with an unexpected_message alert."

Some minor comments=
/typos:

-> "PSK" and "pre-shared key" is used=
 alternately in the draft
-> Section 2, 2nd paragraph: "Incase&q=
uot; -> "In case"
-> Section 5.2, 2nd paragraph: "P=
lease note that, Server MUST include this extension ...". I would chan=
ge this to "Servers MUST NOT send this extension unless the client sen=
t it in the client hello."
-> Section 5.3: A "(" is mi=
ssing in the diagram below "ServerHello"
-> There are some =
more typos. Do you have a Git repository where I could post a pull request =
for those? I guess that would be more efficient than listing them here.
=

Thanks and Cheers,
Andi Walz

___________________________________

Andreas Walz
Research Engineer
Insti=
tute of reliable Embedded Systems and Communication Electronics (ivESK)
=
Offenburg University of Applied Sciences, 77652 Offenburg, Germany

=C2=A0

>>> Raja=C2=A0ashok=C2=
=A0<raja.asho=
k@huawei.com> 01/11/17 1:31 PM >>>
Hi All

A new extension is proposed for [D]TLS1.=
2 and its lower version(not for [D]TLS1.3), to send PSKID in client hello m=
sg instead of client key exchange msg. Using this extension, client can sen=
d its list of PSKIDs to server in its hello msg and server can select any o=
ne of them and respond in its hello msg. 
    - With the help of this ex=
tn, PSK cipher handshake can be completed in 1RTT. Messages exchanged are s=
imilar to resumption.
    - For DHE_PSK, RSA_PSK and ECDHE_PSK ciphers, =
PSKID in client hello msg gives additional information to server for cipher=
 negotiation. If unknown PSKIDs are present, then server can select any NON=
 PSK cipher or fail at that place only (instead of failing in finished mess=
age verification).

Already we received interest and review comments =
from Nikos Mavrogiannopoulos, David Woodhouse and Andreas Walz. Based on th=
at we have submitted the 3rd version of this document. 
I am requesting =
other members of this group also to look into and provide comments for furt=
her improvements.

Regards,
Raja Ashok V K
Huawei Technologies<=
br>Bangalore, India
=
http://www.huawei.com 

=E6=9C=AC=E9=82=AE=E4=BB=B6=E5=8F=8A=E5=
=85=B6=E9=99=84=E4=BB=B6=E5=90=AB=E6=9C=89=E5=8D=8E=E4=B8=BA=E5=85=AC=E5=8F=
=B8=E7=9A=84=E4=BF=9D=E5=AF=86=E4=BF=A1=E6=81=AF=EF=BC=8C=E4=BB=85=E9=
=99=90=E4=BA=8E=E5=8F=91=E9=80=81=E7=BB=99=E4=B8=8A=E9=9D=A2=E5=9C=B0=E5=9D=
=80=E4=B8=AD=E5=88=97=E5=87=BA=E7=9A=84=E4=B8=AA=E4=BA=BA=E6=88=96=E7=BE=A4=
=E7=BB=84=E3=80=82=E7=A6=81
=E6=AD=A2=E4=BB=BB=E4=BD=95=E5=85=B6=E4=BB=
=96=E4=BA=BA=E4=BB=A5=E4=BB=BB=E4=BD=95=E5=BD=A2=E5=BC=8F=E4=BD=BF=E7=94=A8=
=EF=BC=88=E5=8C=85=E6=8B=AC=E4=BD=86=E4=B8=8D=E9=99=90=E4=BA=8E=E5=85=A8=E9=
=83=A8=E6=88=96=E9=83=A8=E5=88=86=E5=9C=B0=E6=B3=84=E9=9C=B2=E3=80=81=
=E5=A4=8D=E5=88=B6=E3=80=81=E6=88=96=E6=95=A3=E5=8F=91=EF=BC=89=E6=9C=AC=E9=
=82=AE=E4=BB=B6=E4=B8=AD
=E7=9A=84=E4=BF=A1=E6=81=AF=E3=80=82=E5=A6=82=
=E6=9E=9C=E6=82=A8=E9=94=99=E6=94=B6=E4=BA=86=E6=9C=AC=E9=82=AE=E4=BB=B6=EF=
=BC=8C=E8=AF=B7=E6=82=A8=E7=AB=8B=E5=8D=B3=E7=94=B5=E8=AF=9D=E6=88=96=
=E9=82=AE=E4=BB=B6=E9=80=9A=E7=9F=A5=E5=8F=91=E4=BB=B6=E4=BA=BA=E5=B9=B6=E5=
=88=A0=E9=99=A4=E6=9C=AC=E9=82=AE=E4=BB=B6=EF=BC=81
This e-mail and its =
attachments contain confidential information from HUAWEI, which 
is inte=
nded only for the person or entity whose address is listed above. Any use o=
f the 
information contained herein in any way (including, but not limit=
ed to, total or partial 
disclosure, reproduction, or dissemination) by =
persons other than the intended 
recipient(s) is prohibited. If you rece=
ive this e-mail in error, please notify the sender by 
phone or email im=
mediately and delete it!

-----Original Message-----
From: internet-drafts@ietf=
.org [mailto:internet-drafts@ietf.org] 
Sent: 17 December 2016 04:11
=
To: Raja ashok; Raja ashok; Jayaraghavendran Kuppannan
Subject: New Vers=
ion Notification for draft-jay-tls-psk-identity-extension-02.txt

A new version of I-D, draft-jay-tls-psk-identity-extension-02.tx=
t
has been successfully submitted by Raja Ashok V K and posted to the IE=
TF repository.

Name:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
draft-jay-tls-psk-identity-extension
Revision:=C2=A0=C2=A0=C2=A0=C2=
=A002
Title:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0TLS/DTLS PSK=
 Identity Extension
Document date:=C2=A0=C2=A0=C2=A0=C2=A02016-12-15
=
Group:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Individual Submission=

Pages:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A010
URL:       =
     https://www.ietf.org/internet-drafts/draft-jay-tls-psk-identity-extension-02.txt
Status:    =
     https://datatracker.ietf.org/doc/draft-=
jay-tls-psk-identity-extension/
Htmlized:       https://tools.ietf.org/html/draft-jay-tls-psk-identity-ex=
tension-02
Diff:           https://ww=
w.ietf.org/rfcdiff?url2=3Ddraft-jay-tls-psk-identity-extension-02=


Abstract:
   Pre-Shared Key (PSK) based Key Exchange Mechani=
sm is primarily used
   in constrained environments where resource inten=
sive Asymmetric
   Cryptography cannot be used. In the Internet of Thing=
s (IoT)
   deployments, constrained devices are commonly used for collec=
ting
   data via sensors for use in home automation, smart energy etc. I=
n
   this context, DTLS is being considered as the primary protocol for<=
br>   communication security at the application layer and in some cases, it=

   is also being considered for network access authentication.

 =
  This document provides a specification for a new extension for
   Opti=
mizing DTLS and TLS Handshake when the Pre-Shared Key (PSK) based
   Key=
 Exchange is used. This extension is aimed at reducing the number
   of =
messages exchanged and the RTT of the TLS & DTLS Handshakes.

   =
                                                                           =
    
Hi, 

I am submitting my 3rd version of our draft(draft-jay-t=
ls-psk-identity-extension) in TLS working group. 

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

The IETF Secretariat

<=
/div>
__________________________________________=
_____
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





--001a114b5b48cfa5ce0545f67038--


From nobody Sun Jan 15 16:51:44 2017
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 E6D871293E0 for ; Sun, 15 Jan 2017 16:51:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.401
X-Spam-Level: 
X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, 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 Q-BCxTJALamY for ; Sun, 15 Jan 2017 16:51:41 -0800 (PST)
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 9C221127058 for ; Sun, 15 Jan 2017 16:51:41 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id B83F3B810FE; Sun, 15 Jan 2017 16:51:40 -0800 (PST)
To: dkg@fifthhorseman.net, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, sean+ietf@sn3rd.com, joe@salowey.net
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Message-Id: <20170116005140.B83F3B810FE@rfc-editor.org>
Date: Sun, 15 Jan 2017 16:51:40 -0800 (PST)
Archived-At: 
Cc: tls@ietf.org, rfc-editor@rfc-editor.org
Subject: [TLS] [Technical Errata Reported] RFC7919 (4908)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 16 Jan 2017 00:51:43 -0000

The following errata report has been submitted for RFC7919,
"Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7919&eid=4908

--------------------------------------
Type: Technical
Reported by: Martin Thomson 

Section: 4

Original Text
-------------
   If a compatible TLS server receives a Supported Groups extension from
   a client that includes any FFDHE group (i.e., any codepoint between
   256 and 511, inclusive, even if unknown to the server), and if none
   of the client-proposed FFDHE groups are known and acceptable to the
   server, then the server MUST NOT select an FFDHE cipher suite.  In
   this case, the server SHOULD select an acceptable non-FFDHE cipher
   suite from the client's offered list.  If the extension is present
   with FFDHE groups, none of the client's offered groups are acceptable
   by the server, and none of the client's proposed non-FFDHE cipher
   suites are acceptable to the server, the server MUST end the
   connection with a fatal TLS alert of type insufficient_security(71).

Corrected Text
--------------
   If a compatible TLS server receives a Supported Groups extension from
   a client that includes any FFDHE group (i.e., any codepoint between
   256 and 511, inclusive, even if unknown to the server), and if none
   of the client-proposed FFDHE groups are known and acceptable to the
   server, then the server MUST NOT select an FFDHE cipher suite.  In
   this case, the server SHOULD select an acceptable non-FFDHE cipher
   suite from the client's offered list.

Notes
-----
The text is overly prescriptive about the alert code that needs to used if there are no acceptable cipher suites available.  If the server is unable to pick a cipher suite, it can send a handshake_failure(40) alert, which this text would prohibit.  handshake_failure is at least equally valid in practice.

This eliminates the prescriptive text about the alert type.

Servers eliminate cipher suites from considerations in numerous ways.  Being able to definitively identify the reason as a (perceived) shortcoming in the strength of the offered security is actually quite challenging in practice.

It's true that insufficient_security is perhaps a more desirable code to use in this case, but it's not generically possible to determine that the server configuration is "more secure" than the combinations on offer by the client.  Consider also the possibility that it's the server that is insecure because it doesn't some of the options offered by the client.  That's a general criticism of the value of insufficient_security, but it should at least motivate why insufficient_security should never be mandated in this way.

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. 

--------------------------------------
RFC7919 (draft-ietf-tls-negotiated-ff-dhe-10)
--------------------------------------
Title               : Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)
Publication Date    : August 2016
Author(s)           : D. Gillmor
Category            : PROPOSED STANDARD
Source              : Transport Layer Security
Area                : Security
Stream              : IETF
Verifying Party     : IESG


From nobody Sun Jan 15 17:00:59 2017
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 AD90D129449 for ; Sun, 15 Jan 2017 17:00:57 -0800 (PST)
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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 02ibwGZkMyM8 for ; Sun, 15 Jan 2017 17:00:55 -0800 (PST)
Received: from mail-qt0-x243.google.com (mail-qt0-x243.google.com [IPv6:2607:f8b0:400d:c0d::243]) (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 B2293129411 for ; Sun, 15 Jan 2017 17:00:55 -0800 (PST)
Received: by mail-qt0-x243.google.com with SMTP id a29so12751705qtb.1 for ; Sun, 15 Jan 2017 17:00:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=1mZq9fGq8AWEiLQ4/wqJ4KPaOTOJMFRSAJ5RmvVvZGQ=; b=avrH2bq5qEzXY+Qz33Adk/HhWagjoUOg9SbCQMUP6HPfHSO6+bSu1Gnn0HzhgCXDyG DLECWD5ksjgXcWGqhb3FuvmS9sX4OYc62FTSdOkdLXicUnLSMAihFD8giAJdcGma1vhx FaYwinzGI4J4GywvZXclPLXeeq4JtaSxRJqYFV6wx46ih7oeMekMF/ZOVfnu0gjF1tMO PySTqLsJmf/IYhrwTmno0daRqpgaxFGGN+049R3icVok4SO0dcrDODfcg5vNlTvTlhU9 5tPXhCv8RDUHr49CxtkXW0WL4l7wXHqLT0Qie0CzYV3ZoSYF3xjbdQZtuLPXNC+3anLW VBBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=1mZq9fGq8AWEiLQ4/wqJ4KPaOTOJMFRSAJ5RmvVvZGQ=; b=AcY3pPzsLthzyg/AxZR7Rl1QfwEvNDxF5FmdtBNaEeb1seMo/lJzLf8+A91uWxLjmL 9X7tqzap8ZoLe12oldWMJH5qPEf8lPAXj8xXwU3U9gPx2JgmTDVJfAOQm6V4DuQhg5jN aejQzzb1T1yry/lX4SQtlSg6qUgoOVXLq666+8OomNpI8fccfvjatt3Byk+GWn/63LIv I7TSl6l0Pa8qRDXlruBDt+HrgCsWp2xkVMfDvjtRdyG84hdJFSdOZNKGTwqhm37nZJ8o TBucnJLCX0xet4hrGZ4t4o6OSQh/oxaZAUWqaDOZ+/F9HzOKLSFFyN3rY44f4nY1FAji e8qA==
X-Gm-Message-State: AIkVDXJkXebCYtXq5V95COpMOl0N06iGL2I5OZveqOP5lYw6oRGAGK49WYUTwasDqD3wdq+Q3sLakDio73FO7Q==
X-Received: by 10.200.35.14 with SMTP id a14mr26423651qta.159.1484528454683; Sun, 15 Jan 2017 17:00:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.19.112 with HTTP; Sun, 15 Jan 2017 17:00:54 -0800 (PST)
In-Reply-To: <20170116005140.B83F3B810FE@rfc-editor.org>
References: <20170116005140.B83F3B810FE@rfc-editor.org>
From: Martin Thomson 
Date: Mon, 16 Jan 2017 14:00:54 +1300
Message-ID: 
To: RFC Errata System 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: sean+ietf@sn3rd.com, Kathleen Moriarty , "tls@ietf.org" 
Subject: Re: [TLS] [Technical Errata Reported] RFC7919 (4908)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 16 Jan 2017 01:00:58 -0000

For those interested in the guts, this came up when discussing
https://bugzilla.mozilla.org/show_bug.cgi?id=3D1330618 where Hubert
noted that NSS is not compliant with this requirement.

On 16 January 2017 at 13:51, RFC Errata System
 wrote:
> The following errata report has been submitted for RFC7919,
> "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transpor=
t Layer Security (TLS)".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3D7919&eid=3D4908
>
> --------------------------------------
> Type: Technical
> Reported by: Martin Thomson 
>
> Section: 4
>
> Original Text
> -------------
>    If a compatible TLS server receives a Supported Groups extension from
>    a client that includes any FFDHE group (i.e., any codepoint between
>    256 and 511, inclusive, even if unknown to the server), and if none
>    of the client-proposed FFDHE groups are known and acceptable to the
>    server, then the server MUST NOT select an FFDHE cipher suite.  In
>    this case, the server SHOULD select an acceptable non-FFDHE cipher
>    suite from the client's offered list.  If the extension is present
>    with FFDHE groups, none of the client's offered groups are acceptable
>    by the server, and none of the client's proposed non-FFDHE cipher
>    suites are acceptable to the server, the server MUST end the
>    connection with a fatal TLS alert of type insufficient_security(71).
>
> Corrected Text
> --------------
>    If a compatible TLS server receives a Supported Groups extension from
>    a client that includes any FFDHE group (i.e., any codepoint between
>    256 and 511, inclusive, even if unknown to the server), and if none
>    of the client-proposed FFDHE groups are known and acceptable to the
>    server, then the server MUST NOT select an FFDHE cipher suite.  In
>    this case, the server SHOULD select an acceptable non-FFDHE cipher
>    suite from the client's offered list.
>
> Notes
> -----
> The text is overly prescriptive about the alert code that needs to used i=
f there are no acceptable cipher suites available.  If the server is unable=
 to pick a cipher suite, it can send a handshake_failure(40) alert, which t=
his text would prohibit.  handshake_failure is at least equally valid in pr=
actice.
>
> This eliminates the prescriptive text about the alert type.
>
> Servers eliminate cipher suites from considerations in numerous ways.  Be=
ing able to definitively identify the reason as a (perceived) shortcoming i=
n the strength of the offered security is actually quite challenging in pra=
ctice.
>
> It's true that insufficient_security is perhaps a more desirable code to =
use in this case, but it's not generically possible to determine that the s=
erver configuration is "more secure" than the combinations on offer by the =
client.  Consider also the possibility that it's the server that is insecur=
e because it doesn't some of the options offered by the client.  That's a g=
eneral criticism of the value of insufficient_security, but it should at le=
ast motivate why insufficient_security should never be mandated in this way=
.
>
> 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.
>
> --------------------------------------
> RFC7919 (draft-ietf-tls-negotiated-ff-dhe-10)
> --------------------------------------
> Title               : Negotiated Finite Field Diffie-Hellman Ephemeral Pa=
rameters for Transport Layer Security (TLS)
> Publication Date    : August 2016
> Author(s)           : D. Gillmor
> Category            : PROPOSED STANDARD
> Source              : Transport Layer Security
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG


From nobody Sun Jan 15 17:02:32 2017
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 E8BE6129411 for ; Sun, 15 Jan 2017 17:02:30 -0800 (PST)
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 (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 TRK5bIkr-oZD for ; Sun, 15 Jan 2017 17:02:29 -0800 (PST)
Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 319121293E0 for ; Sun, 15 Jan 2017 17:02:29 -0800 (PST)
Received: by mail-qt0-x235.google.com with SMTP id v23so92183188qtb.0 for ; Sun, 15 Jan 2017 17:02:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=Hc/gOHiKPJq0byWjzfNly0NJREpL0M9oxnlIYXnL0X0=; b=Oll+ubax0kyYc+UNZ/khO1P6zRLOhBFCCIr0/a0fNOz/uvse1nayKEx7ksM8XqpAZY EHj5q2MVbfS6bYUSaVymVQa5mOBVoMdYob5gNZEkOPZJuXDHWCgJi+SeHc5MDltWdVgx dfdQW+xsnUmFL2TN5kBBpAyXDxwG12AXnczQw=
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 :content-transfer-encoding:message-id:references:to; bh=Hc/gOHiKPJq0byWjzfNly0NJREpL0M9oxnlIYXnL0X0=; b=d80YYEpKMew+kgs5XXjVHo9tn6080icm2GLKVDD5Sys414QiyBNJKFjPDoIQeYj8Bt eMLL0aqb+I32OrwgJzphMhQhUf++xuMJS1x7+cTv5I+hHqYVLBfuOf2pYyC8eCEU9ACf wK0PwamF3jSXxGSBYh983JVrSU9XZYLPqgaMf3qcw6qhY57DHLgWLupvi65z5hYxD9yG STCYasRbvVAKCwDD+tVY5sKUPr6f+Su+WGXfJY5Dz/0XgqeRZBigE0U6pULVKD7Ku1HO I73HjFzQIY0BTyqjLpOS5eT2TETZfGHbnueOJn7pdLzzdNinXwYyNum5ZOVRDGZly9oJ 9YaA==
X-Gm-Message-State: AIkVDXK+y9T6Ci9KAu867jSbd0AoiMlUHBKBElDj0JWrHelBVB0zbmY4AzTj/NEo5yZbYA==
X-Received: by 10.237.51.65 with SMTP id u59mr26566441qtd.190.1484528548057; Sun, 15 Jan 2017 17:02:28 -0800 (PST)
Received: from [5.5.33.164] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id b64sm14993139qkc.25.2017.01.15.17.02.24 for  (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 15 Jan 2017 17:02:26 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Sean Turner 
In-Reply-To: <148420159031.8175.9142724600491868931.idtracker@ietfa.amsl.com>
Date: Sun, 15 Jan 2017 21:02:16 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <45A3FDD7-F874-4377-8E5C-1A6B7B7B7080@sn3rd.com>
References: <148420159031.8175.9142724600491868931.idtracker@ietfa.amsl.com>
To: "" 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-11.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 16 Jan 2017 01:02:31 -0000

Please have a look at -10 and -11 because I believe -11 addresses all =
known issues except the context issue, which we are waiting on input =
from the CFRG on.

spt

> On Jan 12, 2017, at 01:13, internet-drafts@ietf.org wrote:
>=20
>=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 of the IETF.
>=20
>        Title           : Elliptic Curve Cryptography (ECC) Cipher =
Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier
>        Authors         : Yoav Nir
>                          Simon Josefsson
>                          Manuel Pegourie-Gonnard
> 	Filename        : draft-ietf-tls-rfc4492bis-11.txt
> 	Pages           : 32
> 	Date            : 2017-01-11
>=20
> Abstract:
>   This document describes key exchange algorithms based on Elliptic
>   Curve Cryptography (ECC) for the Transport Layer Security (TLS)
>   protocol.  In particular, it specifies the use of Ephemeral Elliptic
>   Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and =
the
>   use of Elliptic Curve Digital Signature Algorithm (ECDSA) and =
Edwards
>   Digital Signature Algorithm (EdDSA) as authentication mechanisms.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/
>=20
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-11
>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-rfc4492bis-11
>=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
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From nobody Sun Jan 15 17:07:37 2017
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 3E3C31293E0 for ; Sun, 15 Jan 2017 17:07:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.5
X-Spam-Level: 
X-Spam-Status: No, score=-7.5 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, RP_MATCHES_RCVD=-3.199, 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 DbiqYCD-Rb42 for ; Sun, 15 Jan 2017 17:07:33 -0800 (PST)
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 6F0BE127058 for ; Sun, 15 Jan 2017 17:07:32 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C4C19BE47; Mon, 16 Jan 2017 01:07:30 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
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 o-Ko1F7h-9FI; Mon, 16 Jan 2017 01:07:29 +0000 (GMT)
Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 78240BE3E; Mon, 16 Jan 2017 01:07:28 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1484528849; bh=ejQvrDE/9VMOxIekZKs+CPzlOI5W5jtWhmWeCKJYod0=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=KOthM/5mk+ESTaSXw9ogpRF62dZQ66fLLZkObgJUYxOErJ8femWf/4Y4ADa3yw3ja cwaLMJC1lehTd0w5Il6QP67I41dFQTLhxjOKGLOV8AB3Qi10bP4G9cwdGqdb8StaAT YloGWLegcLozojiM5GovWBbH2DCekxxiBZKnGFQA=
To: Martin Thomson , RFC Errata System 
References: <20170116005140.B83F3B810FE@rfc-editor.org> 
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <99a11096-70d0-1208-bb4a-8403060826c0@cs.tcd.ie>
Date: Mon, 16 Jan 2017 01:07:28 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050701000909020202070802"
Archived-At: 
Cc: Kathleen Moriarty , sean+ietf@sn3rd.com, "tls@ietf.org" 
Subject: Re: [TLS] [Technical Errata Reported] RFC7919 (4908)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 16 Jan 2017 01:07:36 -0000

This is a cryptographically signed message in MIME format.

--------------ms050701000909020202070802
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


On instruction from the WG chairs, or by acclamation, I will
approve this erratum. Silence OTOH means inaction:-)

S

On 16/01/17 01:00, Martin Thomson wrote:
> For those interested in the guts, this came up when discussing
> https://bugzilla.mozilla.org/show_bug.cgi?id=3D1330618 where Hubert
> noted that NSS is not compliant with this requirement.
>=20
> On 16 January 2017 at 13:51, RFC Errata System
>  wrote:
>> The following errata report has been submitted for RFC7919,
>> "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Trans=
port Layer Security (TLS)".
>>
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=3D7919&eid=3D4908
>>
>> --------------------------------------
>> Type: Technical
>> Reported by: Martin Thomson 
>>
>> Section: 4
>>
>> Original Text
>> -------------
>>    If a compatible TLS server receives a Supported Groups extension fr=
om
>>    a client that includes any FFDHE group (i.e., any codepoint between=

>>    256 and 511, inclusive, even if unknown to the server), and if none=

>>    of the client-proposed FFDHE groups are known and acceptable to the=

>>    server, then the server MUST NOT select an FFDHE cipher suite.  In
>>    this case, the server SHOULD select an acceptable non-FFDHE cipher
>>    suite from the client's offered list.  If the extension is present
>>    with FFDHE groups, none of the client's offered groups are acceptab=
le
>>    by the server, and none of the client's proposed non-FFDHE cipher
>>    suites are acceptable to the server, the server MUST end the
>>    connection with a fatal TLS alert of type insufficient_security(71)=
=2E
>>
>> Corrected Text
>> --------------
>>    If a compatible TLS server receives a Supported Groups extension fr=
om
>>    a client that includes any FFDHE group (i.e., any codepoint between=

>>    256 and 511, inclusive, even if unknown to the server), and if none=

>>    of the client-proposed FFDHE groups are known and acceptable to the=

>>    server, then the server MUST NOT select an FFDHE cipher suite.  In
>>    this case, the server SHOULD select an acceptable non-FFDHE cipher
>>    suite from the client's offered list.
>>
>> Notes
>> -----
>> The text is overly prescriptive about the alert code that needs to use=
d if there are no acceptable cipher suites available.  If the server is u=
nable to pick a cipher suite, it can send a handshake_failure(40) alert, =
which this text would prohibit.  handshake_failure is at least equally va=
lid in practice.
>>
>> This eliminates the prescriptive text about the alert type.
>>
>> Servers eliminate cipher suites from considerations in numerous ways. =
 Being able to definitively identify the reason as a (perceived) shortcom=
ing in the strength of the offered security is actually quite challenging=
 in practice.
>>
>> It's true that insufficient_security is perhaps a more desirable code =
to use in this case, but it's not generically possible to determine that =
the server configuration is "more secure" than the combinations on offer =
by the client.  Consider also the possibility that it's the server that i=
s insecure because it doesn't some of the options offered by the client. =
 That's a general criticism of the value of insufficient_security, but it=
 should at least motivate why insufficient_security should never be manda=
ted in this way.
>>
>> 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.
>>
>> --------------------------------------
>> RFC7919 (draft-ietf-tls-negotiated-ff-dhe-10)
>> --------------------------------------
>> Title               : Negotiated Finite Field Diffie-Hellman Ephemeral=
 Parameters for Transport Layer Security (TLS)
>> Publication Date    : August 2016
>> Author(s)           : D. Gillmor
>> Category            : PROPOSED STANDARD
>> Source              : Transport Layer Security
>> Area                : Security
>> Stream              : IETF
>> Verifying Party     : IESG
>=20


--------------ms050701000909020202070802
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
CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw
aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA
Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra
C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3
rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5
R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r
dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt
3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ
QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv
BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5
BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu
Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll
bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc
MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE
MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG
9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD
C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9
U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM
aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai
9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC
BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs
IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv
mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm
VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4
D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI
dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu
N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE
FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE
WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG
JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+
SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g
BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv
bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY
0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF
NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9
uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p
6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv
Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu
mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7
RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO
/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN
JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM
MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA
oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMTYw
MTA3MjhaMC8GCSqGSIb3DQEJBDEiBCDWaIaq05VbuUUQzKm9+OQIYMRXvR7eNyyWe+ouHQYX
pTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB
nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD
VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq
hkiG9w0BAQEFAASCAQAiy1CRIIToOG4xQnBe39Klpd6Esb68imHnOCyr0pxYgslW59wcEAR4
UeK7G7KRB1mh2Gi/Ykjx71exFJvJJcjUt3skgGxZMiNoWgoRudJrsuSkgxiJ2qQcuTbiXve6
xwgC7gxIpn2u9gyngGNKrZvrqHlPWusFwXKrIrsghxSb90BYBBWkdF3v4h0n/VKgg/xuwyd1
8Z4onHVOaew0Gnj4DHVT34Yu/u78i5KeivalyEXS58RZ8b641UDMcgcL3Npulu0KQkWOpJXb
odULJ7W1v04ZFPcudCqsL1YJHRk7LVaoRRpXTHWyzrIs6tEWwN0bMmBe3telcfZDqtFhEaAk
AAAAAAAA
--------------ms050701000909020202070802--


From nobody Sun Jan 15 18:06:24 2017
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 8457C129449 for ; Sun, 15 Jan 2017 18:06:23 -0800 (PST)
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, 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 M9aPDdU5yMXP for ; Sun, 15 Jan 2017 18:06:21 -0800 (PST)
Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::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 BAACC1293E8 for ; Sun, 15 Jan 2017 18:06:21 -0800 (PST)
Received: by mail-yb0-x22e.google.com with SMTP id l23so30362959ybj.2 for ; Sun, 15 Jan 2017 18:06:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=McsscJPQ+0+npM4q6ipYEnVlrWZEK68kXRp+SupxDO4=; b=m5958+uG0qLti/ZkSXYKcRO4gr3SmDW5G1TnxHze7D7ZZWZcMSwgH3b2drqRiWbUgd a1LcHbMv2XVnH5VeJd6HD0SUHjYy6GKmvIxr17jc3kBFEhYyQCxtSI/PdARpEwN8YzyC ALgcJFsGyml2IiLqxJgM+hy1DrUjXWldYQEN1RTjJ0AHSJ6kkABS+MYfbz+zcSblU7Et UG7Zll7sA9opJZhJFAIle247njYUBcZLN9mK/ryFGka8i8xnWdujDLlCxqUowsJwrhFa SnZ/6aOVnUulxNpu83qJwLAPrZ+ay3xPFJLOhIjJjRWEQJeE3ONOBQkpdtTo1B1ZzIis Ojzg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=McsscJPQ+0+npM4q6ipYEnVlrWZEK68kXRp+SupxDO4=; b=kYmckFxWRwEKK/IRqH2fjDE+msbIT1ajq+3n5vwu6lcAvjBlkTvJyFW2pWuzW+lcNg ChT/8XdXjDKJXaMbE28ufxE5lIiS6vCg4q/jUNh3+1RIrNQqNdOYdBJOjqhKKeTUoPDv DdIHR8JK2c+iysKsY9535K/wd9QClMOjgBXh165WWj4iibUTN9TFfLQfnBLkwSOglgwk 8+hD80e1AKdMoncY5RQuWAlrRsqfOyZ13VOauSmGMmG5L5v44/qweQcMMFaOlSbgO7OD QHwzCfXyFP1pem8hkmAXeGagevPJzWHGkgXUa/NLNE6fmuZeqituYg79p0VXGN9c/hhN Ytcg==
X-Gm-Message-State: AIkVDXL4gnKpUgcPRMeDIdB7U4vpJzXeVWllG8YPxUr/18JT9XznZz/sFhUqy7xzat1jAio/cql0QdkvUbdtbg==
X-Received: by 10.37.246.10 with SMTP id t10mr20929825ybd.107.1484532380885; Sun, 15 Jan 2017 18:06:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.13.204.80 with HTTP; Sun, 15 Jan 2017 18:05:40 -0800 (PST)
In-Reply-To: <99a11096-70d0-1208-bb4a-8403060826c0@cs.tcd.ie>
References: <20170116005140.B83F3B810FE@rfc-editor.org>  <99a11096-70d0-1208-bb4a-8403060826c0@cs.tcd.ie>
From: Eric Rescorla 
Date: Sun, 15 Jan 2017 18:05:40 -0800
Message-ID: 
To: Stephen Farrell 
Content-Type: multipart/alternative; boundary=f403045dc8583887fb05462ca13f
Archived-At: 
Cc: "tls@ietf.org" , Kathleen Moriarty , sean+ietf@sn3rd.com, RFC Errata System 
Subject: Re: [TLS] [Technical Errata Reported] RFC7919 (4908)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 16 Jan 2017 02:06:23 -0000

--f403045dc8583887fb05462ca13f
Content-Type: text/plain; charset=UTF-8

I am in favor of this erratum, or rather of correcting it

On Sun, Jan 15, 2017 at 5:07 PM, Stephen Farrell 
wrote:

>
> On instruction from the WG chairs, or by acclamation, I will
> approve this erratum. Silence OTOH means inaction:-)
>
> S
>
> On 16/01/17 01:00, Martin Thomson wrote:
> > For those interested in the guts, this came up when discussing
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1330618 where Hubert
> > noted that NSS is not compliant with this requirement.
> >
> > On 16 January 2017 at 13:51, RFC Errata System
> >  wrote:
> >> The following errata report has been submitted for RFC7919,
> >> "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for
> Transport Layer Security (TLS)".
> >>
> >> --------------------------------------
> >> You may review the report below and at:
> >> http://www.rfc-editor.org/errata_search.php?rfc=7919&eid=4908
> >>
> >> --------------------------------------
> >> Type: Technical
> >> Reported by: Martin Thomson 
> >>
> >> Section: 4
> >>
> >> Original Text
> >> -------------
> >>    If a compatible TLS server receives a Supported Groups extension from
> >>    a client that includes any FFDHE group (i.e., any codepoint between
> >>    256 and 511, inclusive, even if unknown to the server), and if none
> >>    of the client-proposed FFDHE groups are known and acceptable to the
> >>    server, then the server MUST NOT select an FFDHE cipher suite.  In
> >>    this case, the server SHOULD select an acceptable non-FFDHE cipher
> >>    suite from the client's offered list.  If the extension is present
> >>    with FFDHE groups, none of the client's offered groups are acceptable
> >>    by the server, and none of the client's proposed non-FFDHE cipher
> >>    suites are acceptable to the server, the server MUST end the
> >>    connection with a fatal TLS alert of type insufficient_security(71).
> >>
> >> Corrected Text
> >> --------------
> >>    If a compatible TLS server receives a Supported Groups extension from
> >>    a client that includes any FFDHE group (i.e., any codepoint between
> >>    256 and 511, inclusive, even if unknown to the server), and if none
> >>    of the client-proposed FFDHE groups are known and acceptable to the
> >>    server, then the server MUST NOT select an FFDHE cipher suite.  In
> >>    this case, the server SHOULD select an acceptable non-FFDHE cipher
> >>    suite from the client's offered list.
> >>
> >> Notes
> >> -----
> >> The text is overly prescriptive about the alert code that needs to used
> if there are no acceptable cipher suites available.  If the server is
> unable to pick a cipher suite, it can send a handshake_failure(40) alert,
> which this text would prohibit.  handshake_failure is at least equally
> valid in practice.
> >>
> >> This eliminates the prescriptive text about the alert type.
> >>
> >> Servers eliminate cipher suites from considerations in numerous ways.
> Being able to definitively identify the reason as a (perceived) shortcoming
> in the strength of the offered security is actually quite challenging in
> practice.
> >>
> >> It's true that insufficient_security is perhaps a more desirable code
> to use in this case, but it's not generically possible to determine that
> the server configuration is "more secure" than the combinations on offer by
> the client.  Consider also the possibility that it's the server that is
> insecure because it doesn't some of the options offered by the client.
> That's a general criticism of the value of insufficient_security, but it
> should at least motivate why insufficient_security should never be mandated
> in this way.
> >>
> >> 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.
> >>
> >> --------------------------------------
> >> RFC7919 (draft-ietf-tls-negotiated-ff-dhe-10)
> >> --------------------------------------
> >> Title               : Negotiated Finite Field Diffie-Hellman Ephemeral
> Parameters for Transport Layer Security (TLS)
> >> Publication Date    : August 2016
> >> Author(s)           : D. Gillmor
> >> 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
>
>

--f403045dc8583887fb05462ca13f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I am in favor of this erratum, or rather of correcting it<=
div class=3D"gmail_extra">
On Sun, Jan 15, 20=
17 at 5:07 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie><=
/span> wrote:


On instruction from the WG chairs, or by acclamation, I will

approve this erratum. Silence OTOH means inaction:-)



S




On 16/01/17 01:00, Martin Thomson wrote:

> For those interested in the guts, this came up when discussing

> https://bugzilla.mozilla.org/show_bu=
g.cgi?id=3D1330618 where Hubert

> noted that NSS is not compliant with this requirement.

>

> On 16 January 2017 at 13:51, RFC Errata System

> <rfc=
-editor@rfc-editor.org> wrote:

>> The following errata report has been submitted for RFC7919,

>> "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters =
for Transport Layer Security (TLS)".

>>

>> --------------------------------------

>> You may review the report below and at:

>> http://www.rfc-editor.=
org/errata_search.php?rfc=3D7919&eid=3D4908

>>

>> --------------------------------------

>> Type: Technical

>> Reported by: Martin Thomson <martin.thomson@gmail.com>

>>

>> Section: 4

>>

>> Original Text

>> -------------

>>=C2=A0 =C2=A0 If a compatible TLS server receives a Supported Group=
s extension from

>>=C2=A0 =C2=A0 a client that includes any FFDHE group (i.e., any cod=
epoint between

>>=C2=A0 =C2=A0 256 and 511, inclusive, even if unknown to the server=
), and if none

>>=C2=A0 =C2=A0 of the client-proposed FFDHE groups are known and acc=
eptable to the

>>=C2=A0 =C2=A0 server, then the server MUST NOT select an FFDHE ciph=
er suite.=C2=A0 In

>>=C2=A0 =C2=A0 this case, the server SHOULD select an acceptable non=
-FFDHE cipher

>>=C2=A0 =C2=A0 suite from the client's offered list.=C2=A0 If th=
e extension is present

>>=C2=A0 =C2=A0 with FFDHE groups, none of the client's offered g=
roups are acceptable

>>=C2=A0 =C2=A0 by the server, and none of the client's proposed =
non-FFDHE cipher

>>=C2=A0 =C2=A0 suites are acceptable to the server, the server MUST =
end the

>>=C2=A0 =C2=A0 connection with a fatal TLS alert of type insufficien=
t_security(71).

>>

>> Corrected Text

>> --------------

>>=C2=A0 =C2=A0 If a compatible TLS server receives a Supported Group=
s extension from

>>=C2=A0 =C2=A0 a client that includes any FFDHE group (i.e., any cod=
epoint between

>>=C2=A0 =C2=A0 256 and 511, inclusive, even if unknown to the server=
), and if none

>>=C2=A0 =C2=A0 of the client-proposed FFDHE groups are known and acc=
eptable to the

>>=C2=A0 =C2=A0 server, then the server MUST NOT select an FFDHE ciph=
er suite.=C2=A0 In

>>=C2=A0 =C2=A0 this case, the server SHOULD select an acceptable non=
-FFDHE cipher

>>=C2=A0 =C2=A0 suite from the client's offered list.

>>

>> Notes

>> -----

>> The text is overly prescriptive about the alert code that needs to=
 used if there are no acceptable cipher suites available.=C2=A0 If the serv=
er is unable to pick a cipher suite, it can send a handshake_failure(40) al=
ert, which this text would prohibit.=C2=A0 handshake_failure is at least eq=
ually valid in practice.

>>

>> This eliminates the prescriptive text about the alert type.

>>

>> Servers eliminate cipher suites from considerations in numerous wa=
ys.=C2=A0 Being able to definitively identify the reason as a (perceived) s=
hortcoming in the strength of the offered security is actually quite challe=
nging in practice.

>>

>> It's true that insufficient_security is perhaps a more desirab=
le code to use in this case, but it's not generically possible to deter=
mine that the server configuration is "more secure" than the comb=
inations on offer by the client.=C2=A0 Consider also the possibility that i=
t's the server that is insecure because it doesn't some of the opti=
ons offered by the client.=C2=A0 That's a general criticism of the valu=
e of insufficient_security, but it should at least motivate why insufficien=
t_security should never be mandated in this way.

>>

>> Instructions:

>> -------------

>> This erratum is currently posted as "Reported". If neces=
sary, 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.=


>>

>> --------------------------------------

>> RFC7919 (draft-ietf-tls-negotiated-ff-dhe-10)

>> --------------------------------------

>> Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Nego=
tiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer=
 Security (TLS)

>> Publication Date=C2=A0 =C2=A0 : August 2016

>> Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: D. Gillmor

>> Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STAND=
ARD

>> Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Transport=
 Layer Security

>> Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Secu=
rity

>> 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





--f403045dc8583887fb05462ca13f--


From nobody Mon Jan 16 02:04:16 2017
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 A611012956F for ; Mon, 16 Jan 2017 02:04:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.121
X-Spam-Level: 
X-Spam-Status: No, score=-10.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, 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 oOqJR2jLqMil for ; Mon, 16 Jan 2017 02:04:13 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 8EEBD12942F for ; Mon, 16 Jan 2017 02:04:13 -0800 (PST)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9A9D6128D; Mon, 16 Jan 2017 09:59:13 +0000 (UTC)
Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.2.219]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v0G9x840026300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 16 Jan 2017 04:59:10 -0500
Message-ID: <1484560748.3013.9.camel@redhat.com>
From: Nikos Mavrogiannopoulos 
To: RFC Errata System , dkg@fifthhorseman.net, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, sean+ietf@sn3rd.com, joe@salowey.net
Date: Mon, 16 Jan 2017 10:59:08 +0100
In-Reply-To: <20170116005140.B83F3B810FE@rfc-editor.org>
References: <20170116005140.B83F3B810FE@rfc-editor.org>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Mon, 16 Jan 2017 09:59:13 +0000 (UTC)
Archived-At: 
Cc: tls@ietf.org
Subject: Re: [TLS] [Technical Errata Reported] RFC7919 (4908)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 16 Jan 2017 10:04:14 -0000

On Sun, 2017-01-15 at 16:51 -0800, RFC Errata System wrote:

> Original Text
> -------------
>    If a compatible TLS server receives a Supported Groups extension
> from
>    a client that includes any FFDHE group (i.e., any codepoint
> between
>    256 and 511, inclusive, even if unknown to the server), and if
> none
>    of the client-proposed FFDHE groups are known and acceptable to
> the
>    server, then the server MUST NOT select an FFDHE cipher suite.  In
>    this case, the server SHOULD select an acceptable non-FFDHE cipher
>    suite from the client's offered list.  If the extension is present
>    with FFDHE groups, none of the client's offered groups are
> acceptable
>    by the server, and none of the client's proposed non-FFDHE cipher
>    suites are acceptable to the server, the server MUST end the
>    connection with a fatal TLS alert of type
> insufficient_security(71).

I understand there will be servers which cannot follow the alert
recommendations on an RFC, but in that case why not replace the alert
types recommendation with a RECOMMENDED or SHOULD? It is good practice
for an RFC to specify the alerts to be send rather than leaving it up
to the implementer to figure out.

regards,
Nikos


From nobody Mon Jan 16 05:22:12 2017
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 083CA1293F5 for ; Mon, 16 Jan 2017 05:22:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.198
X-Spam-Level: 
X-Spam-Status: No, score=-5.198 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, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-offenburg.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 2pT5QAc4PA4O for ; Mon, 16 Jan 2017 05:22:08 -0800 (PST)
Received: from mx.hs-offenburg.de (mx.hs-offenburg.de [141.79.11.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D943212956F for ; Mon, 16 Jan 2017 05:22:07 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx.hs-offenburg.de (Postfix) with ESMTP id D307C1670E72 for ; Mon, 16 Jan 2017 14:22:04 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-offenburg.de; h=content-type:content-type:mime-version:in-reply-to:references :subject:subject:from:from:date:date:x-mailer:message-id :received:received:received; s=default; t=1484572922; x= 1485436923; bh=qYv0gQVEFWRw/9AHTFegigMNdbZ/T+7kAP1Kxw5w9Hs=; b=P iu1XNppfislaODa6ZEveJ+finShZiMlK3aTnw9QqrGUe3AydnFM10KMF2kV70Zzz hj84dxM/POnWITnJqtKXdgqx89EwMQRe0dgMVLl0e1iJorU4z/4B1RLN1uz2WNjk 858wSmdC5bhw/ewOQJmY25CTb13/s4LlrundZIygvo=
X-Virus-Scanned: amavisd-new at hs-offenburg.de
Received: from mx.hs-offenburg.de ([127.0.0.1]) by localhost (mx.hs-offenburg.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9r1KNRzaid0s for ; Mon, 16 Jan 2017 14:22:02 +0100 (CET)
Received: from gwia2.rz.hs-offenburg.de (gwia2.rz.hs-offenburg.de [141.79.10.30]) by mx.hs-offenburg.de (Postfix) with ESMTPS id EF3371670E54 for ; Mon, 16 Jan 2017 14:21:59 +0100 (CET)
Received: from gw_dom-gwia2-MTA by gwia2.rz.hs-offenburg.de with Novell_GroupWise; Mon, 16 Jan 2017 14:21:59 +0100
Message-Id: <587CD706020000AC00125EDA@gwia2.rz.hs-offenburg.de>
X-Mailer: Novell GroupWise Internet Agent 14.2.1 
Date: Mon, 16 Jan 2017 14:21:58 +0100
From: "Andreas Walz" 
To: 
References:  <5877AE7B020000AC00125968@gwia2.rz.hs-offenburg.de> 
In-Reply-To: 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part625B4BE6.4__="
Archived-At: 
Cc: tls@ietf.org
Subject: Re: [TLS] FW: New Version Notification for draft-jay-tls-psk-identity-extension-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 16 Jan 2017 13:22:11 -0000

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part625B4BE6.4__=
Content-Type: multipart/alternative; boundary="=__Part625B4BE6.5__="

--=__Part625B4BE6.5__=
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hi Jay,

our scenario is the following: we are considering a legacy industrial
communication system with a number of spatially distributed stations.
Inter-station communication is based on a simple proprietary protocol
over a very lean and lossy wireless channel. The channel features 2.4
kbits/s and a bit error rate of up to 1E-4. Packets might take several
hops until they reach their destination.

Despite the aforementioned constraints we would like to use DTLS for
wireless communication between stations. Therefore, we are investigating
the potential to minimize the communication overhead of DTLS, both
during the handshake and for application data datagrams. Every single
byte we can save is welcome.

Currently, our scenario does not involve any internet-related
communication. I could image that because of this IETF's interest in our
use case is small. We would like to stay standard-compliant though and
support any plan or effort that helps scaling (D)TLS down without
sacrificing security.

Thanks and Best Regards,
Andi Walz


___________________________________

Andreas Walz
Research Engineer
Institute of reliable Embedded Systems and Communication Electronics
(ivESK)
Offenburg University of Applied Sciences, 77652 Offenburg, Germany



>>> Jayaraghavendran Kuppannan 
01/13/17 10:27 AM >>>
Hi Andi,
Thanks a lot for your comments. We will be fixing them.

Right now, we don't have the Git Repository for this draft. Will set it
up shortly (within a day or two) and send you the link for the updates
related to the typos.

Also, it would be great, if you could elaborate on your scenario, so
that we can add parts of it in our draft as a part of the use cases. 


Regards,
Jay




On Thu, Jan 12, 2017 at 8:57 PM, Andreas Walz
 wrote:
Dear all,

I read through the draft and I do have some questions/comments which you
can find below:

-> Section 1, 2nd paragraph: Maybe one could mention explicitly that the
new extension allows to do during the Hello phase what would otherwise
be done in separate messages in a separate round trip.
-> Section 3, 2nd paragraph, under a): it is written "...it checks
whether it supports PSK based authentication for its client.". What does
"its client" refer to? This is supposed to refer to the ordinary PSK
handshake where the server only knows the client's network address at
this point in time, isn’t it?
-> Section 5.2, 1st paragraph: "Clients supporting this extension should
include ...". Is there a reason you don't use "SHOULD"?
-> Section 5.2: There is no statement about the order of PSK identities
in the extension. Does it mean the order is of no relevance at all? Why
not allowing the client to express its preferences by means of ordering
the items in the list?
-> Section 5.3: The fact that abbreviating the handshake only works for
pure PSK cipher suites is only mentioned in the third paragraph. Maybe
this can be made more explicit somewhere at the beginning of this
section (e.g. changing the heading to "Abbreviated Handshake for pure
PSK Cipher Suites" or the like)?
-> Section 5.3, 4th paragraph: the last paragraph only states that for
DHE_PSK, RSA_PSK, ECDHE_PSK the server and client key exchange messages
are still required. It doesn't say anything about whether the presence
of the new extension changes the format of these messages. I would
expect that server and client key exchange messages omit the PSK_ID part
then…or do they keep that part? What is the content then? This should be
mentioned somehow, maybe as a separate section?
-> Section 5.3: What is a server (client) expected to do if it receives
a client (server) key exchange message during an abbreviated handshake
(with pure PSK cipher suites)? Maybe mention "During an abbreviated
handshake the server MUST NOT send a server key exchange message and the
client MUST NOT send a client key exchange message. Otherwise the
receiver MUST abort the handshake with an unexpected_message aler-> "PSK" and "pre-shared key" is used alternately in the draft
-> Section 2, 2nd paragraph: "Incase" -> "In case"
-> Section 5.2, 2nd paragraph: "Please note that, Server MUST include
this extension ...". I would change this to "Servers MUST NOT send this
extension unless the client sent it in the client hello."
-> Section 5.3: A "(" is missing in the diagram below "ServerHello"
-> There are some more typos. Do you have a Git repository where I could
post a pull request for those? I guess that would be more efficient than
listing them here.

Thanks and Cheers,
Andi Walz

___________________________________

Andreas Walz
Research Engineer
Institute of reliable Embedded Systems and Communication Electronics
(ivESK)
Offenburg University of Applied Sciences, 77652 Offenburg, Germany






>>> Raja ashok  01/11/17 1:31 PM >>>
Hi All

A new extension is proposed for [D]TLS1.2 and its lower version(not for
[D]TLS1.3), to send PSKID in client hello msg instead of client key
exchange msg. Using this extension, client can send its list of PSKIDs
to server in its hello msg and server can select any one of them and
respond in its hello msg. 
    - With the help of this extn, PSK cipher handshake can be completed
in 1RTT. Messages exchanged are similar to resumption.
    - For DHE_PSK, RSA_PSK and ECDHE_PSK ciphers, PSKID in client hello
msg gives additional information to server for cipher negotiation. If
unknown PSKIDs are present, then server can select any NON PSK cipher or
fail at that place only (instead of failing in finished message
verification).

Already we received interest and review comments from Nikos
Mavrogiannopoulos, David Woodhouse and Andreas Walz. Based on that we
have submitted the 3rd version of this document. 
I am requesting other members of this group also to look into and
provide comments for further improvements.

Regards,
Raja Ashok V K
Huawei Technologies
Bangalore, India
http://www.huawei.com 

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from
HUAWEI, which 
is intended only for the person or entity whose address is listed above.
Any use of the 
information contained herein in any way (including, but not limited to,
total or partial 
disclosure, reproduction, or dissemination) by persons other than the
intended 
recipient(s) is prohibited. If you receive this e-mail in error, please
notify the sender by 
phone or email immediately and delete it!

-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
Sent: 17 December 2016 04:11
To: Raja ashok; Raja ashok; Jayaraghavendran Kuppannan
Subject: New Version Notification for
draft-jay-tls-psk-identity-extension-02.txt


A new version of I-D, draft-jay-tls-psk-identity-extension-02.txt
has been successfully submitted by Raja Ashok V K and posted to the IETF
repository.

Name:        draft-jay-tls-psk-identity-extension
Revision:    02
Title:        TLS/DTLS PSK Identity Extension
Document date:    2016-12-15
Group:        Individual Submission
Pages:        10
URL:           
https://www.ietf.org/internet-drafts/draft-jay-tls-psk-identity-extension-02.txt
Status:        
https://datatracker.ietf.org/doc/draft-jay-tls-psk-identity-extension/
Htmlized:      
https://tools.ietf.org/html/draft-jay-tls-psk-identity-extension-02
Diff:          
https://www.ietf.org/rfcdiff?url2=draft-jay-tls-psk-identity-extension-02

Abstract:
   Pre-Shared Key (PSK) based Key Exchange Mechanism is primarily used
   in constrained environments where resource intensive Asymmetric
   Cryptography cannot be used. In the Internet of Things (IoT)
   deployments, constrained devices are commonly used for collecting
   data via sensors for use in home automation, smart energy etc. In
   this context, DTLS is being considered as the primary protocol for
   communication security at the application layer and in some cases, it
   is also being considered for network access authentication.

   This document provides a specification for a new extension for
   Optimizing DTLS and TLS Handshake when the Pre-Shared Key (PSK) based
   Key Exchange is used. This extension is aimed at reducing the number
   of messages exchanged and the RTT of the TLS & DTLS Handshakes.

                                                                        
         
Hi, 

I am submitting my 3rd version of our
draft(draft-jay-tls-psk-identity-extension) in TLS working group. 

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

The IETF Secretariat



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


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



 


--=__Part625B4BE6.5__=
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
Content-Description: HTML

 =0Abody p =0A{ =0A	margin: 0px; =0A}=0AHi Jay,

our scenario is the following: we are =
considering a legacy industrial communication system with a number of =
spatially distributed stations. Inter-station communication is based on a =
simple proprietary protocol over a very lean and lossy wireless channel. =
The channel features 2.4 kbits/s and a bit error rate of up to 1E-4. =
Packets might take several hops until they reach their destination.

=
Despite the aforementioned constraints we would like to use DTLS for =
wireless communication between stations. Therefore, we are investigating =
the potential to minimize the communication overhead of DTLS, both during =
the handshake and for application data datagrams. Every single byte we can =
save is welcome.

Currently, our scenario does not involve any =
internet-related communication. I could image that because of this IETF's =
interest in our use case is small. We would like to stay standard-compliant=
 though and support any plan or effort that helps scaling (D)TLS down =
without sacrificing security.

Thanks and Best Regards,
Andi =
Walz
=

 _________=
__________________________

Andreas Walz
Research Engineer
Inst=
itute of reliable Embedded Systems and Communication Electronics (ivESK)Offenburg University of Applied Sciences, 77652 Offenburg, Germany

=


>>> Jayaraghavendran Kuppannan <jayaraghavend=
ran.ietf@gmail.com> 01/13/17 10:27 AM >>>
Hi Andi,

Thanks a lot for your comments. We =
will be fixing them.

Right now, we don't have the =
Git Repository for this draft. Will set it up shortly (within a day or =
two) and send you the link for the updates related to the typos.
=

Also, it would be great, if you could elaborate on your =
scenario, so that we can add parts of it in our draft as a part of the use =
cases. 


Regards,
Jay=




On Thu, Jan 12, 2017 at 8:57 PM, Andreas Walz =
<andreas.walz@hs-offenburg.de> wrote:
De=
ar all,

I read through the draft and I do have some questions/commen=
ts which you can find below:

-> Section 1, 2nd paragraph: Maybe =
one could mention explicitly that the new extension allows to do during =
the Hello phase what would otherwise be done in separate messages in a =
separate round trip.
-> Section 3, 2nd paragraph, under a): it is =
written "...it checks whether it supports PSK based authentication for its =
client.". What does "its client" refer to? This is supposed to refer to =
the ordinary PSK handshake where the server only knows the client's =
network address at this point in time, isn=E2=80=99t it?
-> Section =
5.2, 1st paragraph: "Clients supporting this extension should include =
...". Is there a reason you don't use "SHOULD"?
-> Section 5.2: =
There is no statement about the order of PSK identities in the extension. =
Does it mean the order is of no relevance at all? Why not allowing the =
client to express its preferences by means of ordering the items in the =
list?
-> Section 5.3: The fact that abbreviating the handshake only =
works for pure PSK cipher suites is only mentioned in the third paragraph. =
Maybe this can be made more explicit somewhere at the beginning of this =
section (e.g. changing the heading to "Abbreviated Handshake for pure PSK =
Cipher Suites" or the like)?
-> Section 5.3, 4th paragraph: the last =
paragraph only states that for DHE_PSK, RSA_PSK, ECDHE_PSK the server and =
client key exchange messages are still required. It doesn't say anything =
about whether the presence of the new extension changes the format of =
these messages. I would expect that server and client key exchange =
messages omit the PSK_ID part then=E2=80=A6or do they keep that part? What =
is the content then? This should be mentioned somehow, maybe as a separate =
section?
-> Section 5.3: What is a server (client) expected to do if =
it receives a client (server) key exchange message during an abbreviated =
handshake (with pure PSK cipher suites)? Maybe mention "During an =
abbreviated handshake the server MUST NOT send a server key exchange =
message and the client MUST NOT send a client key exchange message. =
Otherwise the receiver MUST abort the handshake with an unexpected_message =
alert."

Some minor comments/typos:

-> "PSK" and "pre-share=
d key" is used alternately in the draft
-> Section 2, 2nd paragraph: =
"Incase" -> "In case"
-> Section 5.2, 2nd paragraph: "Please note =
that, Server MUST include this extension ...". I would change this to =
"Servers MUST NOT send this extension unless the client sent it in the =
client hello."
-> Section 5.3: A "(" is missing in the diagram below =
"ServerHello"
-> There are some more typos. Do you have a Git =
repository where I could post a pull request for those? I guess that would =
be more efficient than listing them here.

Thanks and Cheers,
Andi=
 Walz

___________________________________

Andreas Walz
Res=
earch Engineer
Institute of reliable Embedded Systems and =
Communication Electronics (ivESK)
Offenburg University of =
Applied Sciences, 77652 Offenburg, Germany


&nb=
sp;
>>> Raja ashok <raja.ashok@huawei.com> 01/11/17 1:31 PM =
>>>
Hi All

A new =
extension is proposed for [D]TLS1.2 and its lower version(not for =
[D]TLS1.3), to send PSKID in client hello msg instead of client key =
exchange msg. Using this extension, client can send its list of PSKIDs to =
server in its hello msg and server can select any one of them and respond =
in its hello msg. 
    - With the help of this extn, PSK cipher =
handshake can be completed in 1RTT. Messages exchanged are similar to =
resumption.
    - For DHE_PSK, RSA_PSK and ECDHE_PSK ciphers, PSKID in =
client hello msg gives additional information to server for cipher =
negotiation. If unknown PSKIDs are present, then server can select any NON =
PSK cipher or fail at that place only (instead of failing in finished =
message verification).

Already we received interest and review =
comments from Nikos Mavrogiannopoulos, David Woodhouse and Andreas Walz. =
Based on that we have submitted the 3rd version of this document. 
I am =
requesting other members of this group also to look into and provide =
comments for further improvements.

Regards,
Raja Ashok V =
K
Huawei Technologies
Bangalore, India
http://www.huawei.com 

=E6=9C=AC=E9=82=
=AE=E4=BB=B6=E5=8F=8A=E5=85=B6=E9=99=84=E4=BB=B6=E5=90=AB=E6=9C=89=E5=8D=8E=
=E4=B8=BA=E5=85=AC=E5=8F=B8=E7=9A=84=E4=BF=9D=E5=AF=86=E4=BF=A1=E6=81=AF=EF=
=BC=8C=E4=BB=85=E9=99=90=E4=BA=8E=E5=8F=91=E9=80=81=E7=BB=99=E4=B8=8A=E9=9D=
=A2=E5=9C=B0=E5=9D=80=E4=B8=AD=E5=88=97=E5=87=BA=E7=9A=84=E4=B8=AA=E4=BA=BA=
=E6=88=96=E7=BE=A4=E7=BB=84=E3=80=82=E7=A6=81
=E6=AD=A2=E4=BB=BB=E4=BD=
=95=E5=85=B6=E4=BB=96=E4=BA=BA=E4=BB=A5=E4=BB=BB=E4=BD=95=E5=BD=A2=E5=BC=8F=
=E4=BD=BF=E7=94=A8=EF=BC=88=E5=8C=85=E6=8B=AC=E4=BD=86=E4=B8=8D=E9=99=90=E4=
=BA=8E=E5=85=A8=E9=83=A8=E6=88=96=E9=83=A8=E5=88=86=E5=9C=B0=E6=B3=84=E9=9C=
=B2=E3=80=81=E5=A4=8D=E5=88=B6=E3=80=81=E6=88=96=E6=95=A3=E5=8F=91=EF=BC=89=
=E6=9C=AC=E9=82=AE=E4=BB=B6=E4=B8=AD
=E7=9A=84=E4=BF=A1=E6=81=AF=E3=80=
=82=E5=A6=82=E6=9E=9C=E6=82=A8=E9=94=99=E6=94=B6=E4=BA=86=E6=9C=AC=E9=82=AE=
=E4=BB=B6=EF=BC=8C=E8=AF=B7=E6=82=A8=E7=AB=8B=E5=8D=B3=E7=94=B5=E8=AF=9D=E6=
=88=96=E9=82=AE=E4=BB=B6=E9=80=9A=E7=9F=A5=E5=8F=91=E4=BB=B6=E4=BA=BA=E5=B9=
=B6=E5=88=A0=E9=99=A4=E6=9C=AC=E9=82=AE=E4=BB=B6=EF=BC=81
This e-mail =
and its attachments contain confidential information from HUAWEI, which =

is intended only for the person or entity whose address is listed =
above. Any use of the 
information contained herein in any way =
(including, but not limited to, total or partial 
disclosure, reproducti=
on, or dissemination) by persons other than the intended 
recipient(s) =
is prohibited. If you receive this e-mail in error, please notify the =
sender by 
phone or email immediately and delete it!

-----Origina=
l Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] =

Sent: 17 December 2016 04:11
To: Raja ashok; Raja ashok; Jayaraghave=
ndran Kuppannan
Subject: New Version Notification for draft-jay-tls-psk-=
identity-extension-02.txt


A new version of I-D, draft-jay-tls-ps=
k-identity-extension-02.txt
has been successfully submitted by Raja =
Ashok V K and posted to the IETF repository.

Name:   =
     draft-jay-tls-psk-identity-extension
Revis=
ion:    02
Title:      =
;  TLS/DTLS PSK Identity Extension
Document date:  &=
nbsp; 2016-12-15
Group:       &n=
bsp;Individual Submission
Pages:      &nbs=
p; 10
URL:            https://w=
ww.ietf.org/internet-drafts/draft-jay-tls-psk-identity-extension-02.txt=

Status:         https://datatracker.ietf.org/=
doc/draft-jay-tls-psk-identity-extension/
Htmlized:       https://tools.ietf.org/html/draft-jay-tls-psk-identity-=
extension-02
Diff:           https://=
www.ietf.org/rfcdiff?url2=3Ddraft-jay-tls-psk-identity-extension-02
=

Abstract:
   Pre-Shared Key (PSK) based Key Exchange Mechanism is =
primarily used
   in constrained environments where resource intensive =
Asymmetric
   Cryptography cannot be used. In the Internet of Things =
(IoT)
   deployments, constrained devices are commonly used for =
collecting
   data via sensors for use in home automation, smart energy =
etc. In
   this context, DTLS is being considered as the primary =
protocol for
   communication security at the application layer and in =
some cases, it
   is also being considered for network access authentica=
tion.

   This document provides a specification for a new extension =
for
   Optimizing DTLS and TLS Handshake when the Pre-Shared Key (PSK) =
based
   Key Exchange is used. This extension is aimed at reducing the =
number
   of messages exchanged and the RTT of the TLS & DTLS =
Handshakes.

                                                        =
                          
Hi, 

I am submitting my 3rd version =
of our draft(draft-jay-tls-psk-identity-extension) in TLS working group. =


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

____________________________=
___________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tl=
s
 
__________________________________________=
_____
 TLS mailing list
 TLS@ietf.org=

 https://www.ietf.org/mailman/listinfo/tls
 

 


--=__Part625B4BE6.5__=--

--=__Part625B4BE6.4__=--


From nobody Mon Jan 16 05:32:48 2017
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 7B191129436 for ; Mon, 16 Jan 2017 05:32:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.198
X-Spam-Level: 
X-Spam-Status: No, score=-5.198 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, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-offenburg.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 CvWVcqYyB37L for ; Mon, 16 Jan 2017 05:32:46 -0800 (PST)
Received: from mx.hs-offenburg.de (mx.hs-offenburg.de [141.79.11.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB8AA12942F for ; Mon, 16 Jan 2017 05:32:46 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx.hs-offenburg.de (Postfix) with ESMTP id 0203C167110A for ; Mon, 16 Jan 2017 14:32:45 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-offenburg.de; h=content-type:content-type:mime-version:subject:subject:from :from:date:date:x-mailer:message-id:received:received:received; s=default; t=1484573564; x=1485437565; bh=pGo2QJKXQHoSlOLmqYW2m 6qrqNOmPxJ2n93EPxKEqBo=; b=hWWkVJWA3L3gByKv8x9wlY3ahCMCYzBVVtcPu 00ijJ0jcwezJkPLNQu26HD77mDQ85SGsb3dqlsWYjE4NSTvrXszoXAq8Gefin+bl h69rtjIpNRt3YMwLOYO40vBJdwQJeSWyhHlLCEnI47Y6KpkNcCZgGCWcWvuyUeq3 6k+Vxk=
X-Virus-Scanned: amavisd-new at hs-offenburg.de
Received: from mx.hs-offenburg.de ([127.0.0.1]) by localhost (mx.hs-offenburg.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjYu7_HN5hkO for ; Mon, 16 Jan 2017 14:32:44 +0100 (CET)
Received: from gwia2.rz.hs-offenburg.de (gwia2.rz.hs-offenburg.de [141.79.10.30]) by mx.hs-offenburg.de (Postfix) with ESMTPS id 6A4431671100 for ; Mon, 16 Jan 2017 14:32:44 +0100 (CET)
Received: from gw_dom-gwia2-MTA by gwia2.rz.hs-offenburg.de with Novell_GroupWise; Mon, 16 Jan 2017 14:32:44 +0100
Message-Id: <587CD98A020000AC00125EEE@gwia2.rz.hs-offenburg.de>
X-Mailer: Novell GroupWise Internet Agent 14.2.1 
Date: Mon, 16 Jan 2017 14:32:42 +0100
From: "Andreas Walz" 
To: 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartEDD4C46A.2__="
Archived-At: 
Cc: jayaraghavendran.k@huawei.com
Subject: [TLS] draft-jay-tls-omit-aead-explicit-nonce-extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 16 Jan 2017 13:32:47 -0000

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartEDD4C46A.2__=
Content-Type: multipart/alternative; boundary="=__PartEDD4C46A.3__="

--=__PartEDD4C46A.3__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hi all,

I stumbled upon an expired draft introducing a new (D)TLS extension to =
omit explicit nonces in (D)TLS AEAD cipher modes (draft-jay-tls-omit-aead-e=
xplicit-nonce-extension). For a number of cipher suites, this would allow =
to reduce the per-record overhead in (D)TLS by 8 bytes.

Is there any interest in breathing new life into that draft? In our =
scenario (DTLS for a legacy industrial wireless communication system) =
every single byte counts. That is why we would strongly support reviving =
this draft...

Thanks and Cheers,
Andi Walz


___________________________________

Andreas Walz
Research Engineer
Institute of reliable Embedded Systems and Communication Electronics =
(ivESK)
Offenburg University of Applied Sciences, 77652 Offenburg, Germany

--=__PartEDD4C46A.3__=
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Description: HTML

 =0Abody p =0A{ =0A	margin: 0px; =0A}=0AHi all,

I stumbled upon an expired draft =
introducing a new (D)TLS extension to omit explicit nonces in (D)TLS AEAD =
cipher modes (draft-jay-tls-omit-aead-explicit-nonce-extension). For a =
number of cipher suites, this would allow to reduce the per-record =
overhead in (D)TLS by 8 bytes.

Is there any interest in breathing =
new life into that draft? In our scenario (DTLS for a legacy industrial =
wireless communication system) every single byte counts. That is why we =
would strongly support reviving this draft...

Thanks and Cheers,
=
Andi Walz


___________________________________

Andreas =
Walz
Research Engineer
Institute of reliable Embedded Systems and =
Communication Electronics (ivESK)
Offenburg University of Applied =
Sciences, 77652 Offenburg, Germany

--=__PartEDD4C46A.3__=--

--=__PartEDD4C46A.2__=--


From nobody Mon Jan 16 05:34:09 2017
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 7971B129436 for ; Mon, 16 Jan 2017 05:34:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 1XOdm1PNIpcZ for ; Mon, 16 Jan 2017 05:34:06 -0800 (PST)
Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::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 05DC812942F for ; Mon, 16 Jan 2017 05:34:06 -0800 (PST)
Received: by mail-yw0-x22a.google.com with SMTP id a10so68213367ywa.3 for ; Mon, 16 Jan 2017 05:34:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=J69gGG0QT/ayBTBiuBfO72DVlUgiGzdsVUQhUhoxUns=; b=Nt3J8opys4dK8EM/bmcZ88Tu4JCncfCbMkigdyXG1f4V1H+NqTQPNjS5KJ3MRcF9aX m9UGUJgLkJQm/FHyGswsF5P7Ht40o6Ode/t7o6sUYfPLdVhuzn4RRQSFWB7dZHpRBYDT AorXk+liFxvt2aifa8lLcd89L7wSL+uRSNVFh9rgBxemAHAlmOEszPVw0UhgMHdg7wsb 7NvtPYvo0GiNU0kecd5mPJkty0I15kugFq7fFCJ0YYYHh3DQP9YRF8Z2lHREbJa1mlEB N0wfOQkqlJFd4kct6nn+pbrjf8gjnX5M+zkbwJqpEwXow5WFyq4h8ZIzPqktclOLBPEN Kabg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=J69gGG0QT/ayBTBiuBfO72DVlUgiGzdsVUQhUhoxUns=; b=pPLGsAaQJ1P12M0mr3Q3+ucrtL6USPpHktJAnsOwt2iXi5Fq7Rj63XWEix7NJKmNui 4+IJHqafpC4zZoPYgygeoGW1kBNd1e7dOi/koodZv/nM9DLH+zAkJNFtfxTkl5g78L21 cWTfjo41aSTg8Gybx4NtyLoWT3G9C0PPRcj4UjrbQvuTo05punsAbxY25KdwdY/GoLbS 3TjjDtOQQvQU4JIe/0tukUDFUVhKjdHHZn1c2fwRpLrFDHCIdlF2RdALYCOy8r2nH1lf sxOL9bUFclUNAi0ZbrNW1JBHQFLydxeZfKxYysRTDScZlJmT0pd+xmoxVQB1eM9NoI0/ OATA==
X-Gm-Message-State: AIkVDXLJoOLaOowa6UCCgWI4UEKSgaVvB5DM/oEgNggHc/qhtf32s/aLZLmSh3P9zq0LRjfnyNF8gR7EPxL02A==
X-Received: by 10.129.40.141 with SMTP id o135mr24642812ywo.149.1484573645055;  Mon, 16 Jan 2017 05:34:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.13.204.80 with HTTP; Mon, 16 Jan 2017 05:33:24 -0800 (PST)
In-Reply-To: <1484560748.3013.9.camel@redhat.com>
References: <20170116005140.B83F3B810FE@rfc-editor.org> <1484560748.3013.9.camel@redhat.com>
From: Eric Rescorla 
Date: Mon, 16 Jan 2017 05:33:24 -0800
Message-ID: 
To: Nikos Mavrogiannopoulos 
Content-Type: multipart/alternative; boundary=001a114087a8c1f6620546363c22
Archived-At: 
Cc: sean+ietf@sn3rd.com, Kathleen Moriarty , "tls@ietf.org" , RFC Errata System 
Subject: Re: [TLS] [Technical Errata Reported] RFC7919 (4908)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 16 Jan 2017 13:34:07 -0000

--001a114087a8c1f6620546363c22
Content-Type: text/plain; charset=UTF-8

On Mon, Jan 16, 2017 at 1:59 AM, Nikos Mavrogiannopoulos 
wrote:

> On Sun, 2017-01-15 at 16:51 -0800, RFC Errata System wrote:
>
> > Original Text
> > -------------
> >    If a compatible TLS server receives a Supported Groups extension
> > from
> >    a client that includes any FFDHE group (i.e., any codepoint
> > between
> >    256 and 511, inclusive, even if unknown to the server), and if
> > none
> >    of the client-proposed FFDHE groups are known and acceptable to
> > the
> >    server, then the server MUST NOT select an FFDHE cipher suite.  In
> >    this case, the server SHOULD select an acceptable non-FFDHE cipher
> >    suite from the client's offered list.  If the extension is present
> >    with FFDHE groups, none of the client's offered groups are
> > acceptable
> >    by the server, and none of the client's proposed non-FFDHE cipher
> >    suites are acceptable to the server, the server MUST end the
> >    connection with a fatal TLS alert of type
> > insufficient_security(71).
>
> I understand there will be servers which cannot follow the alert
> recommendations on an RFC, but in that case why not replace the alert
> types recommendation with a RECOMMENDED or SHOULD? It is good practice
> for an RFC to specify the alerts to be send rather than leaving it up
> to the implementer to figure out.


IMO the spec should avoid prescribing alerts that require a certain
structure for
the negotiation code, which is what's happening here. In addition, we should
probably avoid RFC 2119-level requirements which we know that many
implementations will violate, even when they are SHOULD, not MUST

-Ekr

--001a114087a8c1f6620546363c22
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Mon, Jan 16, 2017 at 1:59 AM, Nikos Mavrogiannopoulos <nmav@redhat.co=
m> wrote:
=
On Sun, 2017-01-15 at 16:51 -0800, RFC Errata System wrote:



> Original Text

> -------------

> =C2=A0=C2=A0=C2=A0If a compatible TLS server receives a Supported Grou=
ps extension

> from

> =C2=A0=C2=A0=C2=A0a client that includes any FFDHE group (i.e., any co=
depoint

> between

> =C2=A0=C2=A0=C2=A0256 and 511, inclusive, even if unknown to the serve=
r), and if

> none

> =C2=A0=C2=A0=C2=A0of the client-proposed FFDHE groups are known and ac=
ceptable to

> the

> =C2=A0=C2=A0=C2=A0server, then the server MUST NOT select an FFDHE cip=
her suite.=C2=A0=C2=A0In

> =C2=A0=C2=A0=C2=A0this case, the server SHOULD select an acceptable no=
n-FFDHE cipher

> =C2=A0=C2=A0=C2=A0suite from the client's offered list.=C2=A0=C2=
=A0If the extension is present

> =C2=A0=C2=A0=C2=A0with FFDHE groups, none of the client's offered =
groups are

> acceptable

> =C2=A0=C2=A0=C2=A0by the server, and none of the client's proposed=
 non-FFDHE cipher

> =C2=A0=C2=A0=C2=A0suites are acceptable to the server, the server MUST=
 end the

> =C2=A0=C2=A0=C2=A0connection with a fatal TLS alert of type

> insufficient_security(71).



I understand there will be servers which cannot follow the alert

recommendations on an RFC, but in that case why not replace the alert

types recommendation with a RECOMMENDED or SHOULD? It is good practice

for an RFC to specify the alerts to be send rather than leaving it up

to the implementer to figure out.

IMO the s=
pec should avoid prescribing alerts that require a certain structure for
the negotiation code, which is what's happening here. In additi=
on, we should
probably avoid RFC 2119-level requirements which we=
 know that many
implementations will violate, even when they are =
SHOULD, not MUST

-Ekr
=C2=A0


--001a114087a8c1f6620546363c22--


From nobody Mon Jan 16 05:36:30 2017
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 A83D412942F for ; Mon, 16 Jan 2017 05:36:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 9uQl4wrXG5-m for ; Mon, 16 Jan 2017 05:36:27 -0800 (PST)
Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::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 E51C612896F for ; Mon, 16 Jan 2017 05:36:26 -0800 (PST)
Received: by mail-yw0-x230.google.com with SMTP id l75so68307605ywb.0 for ; Mon, 16 Jan 2017 05:36:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6MicJqGDaR7GIlcaTOH//v75pmuf1B14s67mgGfeOcs=; b=D5sCmDpbgxop4S4YGHM5+s7K9egxJR9zE+2tu0/jIu4jeuemCicrkmd92zqhUJnhCj jISkh4dnZVdnsDexcbgqcTrH6BaTGdRt518GbfuHNWGwe+/27ddoLNJK8o0gQNOVAyIb NfvF2wK8oiiHKuB1eqXN0CxpMW5DAVOvFvZwkT0mPpbmH6owIyx/T0h405f+zhr9aCjf wxun1ePl9pSFx4gHez7Sk+t7eX/YeX1WEhqGk1qcGBnkR9/DBDBnpw444IGM7fjDXPUe ZTY3dLYyU++BWGlI95qfRwQE9EdroMVKMfDju9JFQeY00ML2CFNPK2xIhN2FQFFRy1Ow HmyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6MicJqGDaR7GIlcaTOH//v75pmuf1B14s67mgGfeOcs=; b=CwW9speTvLVKxio4osxl6cLG5GCQYtTo4UCBMtUxEsl2BlOqN00qRgmHjtZxZ1AxDY MwitjV9f3weoERx45KGZJfLRT18xwml+NpmwF/ji3x4ZxOuB/o5Mx1yvc5G+JHoM6nRe Fccb7CX7Hv2ppzSIkoLxrRdAh8fZP9yVfHgQ68J6MjyW0KjTFBIwJ44mKm7/jxy7t4o1 slCMQwiBvFU/Fm2zgqUiUWy1UmDpOdMEGhyThweLBjvgyArL586UltwLyoIIAC/mR9jr 6ekzt9xqzRWDW1MlP5Zn312h5abV0YDavmkizZbce5oHrBOidY2hcvETwe9LiCZ6nd6I eamQ==
X-Gm-Message-State: AIkVDXKBSbuTjN4RR71mMEEqjOHyEm7rbXkilOjUSOh6uPyXIlee2BgiFOijtmyOFEj3n/59OCADpHfB8nlTmQ==
X-Received: by 10.13.221.71 with SMTP id g68mr25380486ywe.21.1484573786066; Mon, 16 Jan 2017 05:36:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.13.204.80 with HTTP; Mon, 16 Jan 2017 05:35:45 -0800 (PST)
In-Reply-To: <587CD98A020000AC00125EEE@gwia2.rz.hs-offenburg.de>
References: <587CD98A020000AC00125EEE@gwia2.rz.hs-offenburg.de>
From: Eric Rescorla 
Date: Mon, 16 Jan 2017 05:35:45 -0800
Message-ID: 
To: Andreas Walz 
Content-Type: multipart/alternative; boundary=94eb2c075f7c29a5ae05463645aa
Archived-At: 
Cc: Jayaraghavendran k , "tls@ietf.org" 
Subject: Re: [TLS] draft-jay-tls-omit-aead-explicit-nonce-extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 16 Jan 2017 13:36:28 -0000

--94eb2c075f7c29a5ae05463645aa
Content-Type: text/plain; charset=UTF-8

Andreas,

DTLS 1.3 will behave this way by default, so it would be better to just
move to 1.3 rather than patching 1.2.

-Ekr


On Mon, Jan 16, 2017 at 5:32 AM, Andreas Walz 
wrote:

> Hi all,
>
> I stumbled upon an expired draft introducing a new (D)TLS extension to
> omit explicit nonces in (D)TLS AEAD cipher modes (draft-jay-tls-omit-aead-explicit-nonce-extension).
> For a number of cipher suites, this would allow to reduce the per-record
> overhead in (D)TLS by 8 bytes.
>
> Is there any interest in breathing new life into that draft? In our
> scenario (DTLS for a legacy industrial wireless communication system) every
> single byte counts. That is why we would strongly support reviving this
> draft...
>
> Thanks and Cheers,
> Andi Walz
>
>
> ___________________________________
>
> Andreas Walz
> Research Engineer
> Institute of reliable Embedded Systems and Communication Electronics
> (ivESK)
> Offenburg University of Applied Sciences, 77652 Offenburg, Germany
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--94eb2c075f7c29a5ae05463645aa
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Andreas,

DTLS 1.3 will behave this way =
by default, so it would be better to just move to 1.3 rather than patching =
1.2.

-Ekr


On Mon, Jan 16, 2017 at 5:32 AM=
, Andreas Walz <andreas.walz@hs-offenburg.de> wro=
te:
Hi all,

I stumbled upon an expired d=
raft introducing a new (D)TLS extension to omit explicit nonces in (D)TLS A=
EAD cipher modes (draft-jay-tls-omit-aead-explicit-nonce-extension). F=
or a number of cipher suites, this would allow to reduce the per-record ove=
rhead in (D)TLS by 8 bytes.

Is there any interest in breathing new l=
ife into that draft? In our scenario (DTLS for a legacy industrial wireless=
 communication system) every single byte counts. That is why we would stron=
gly support reviving this draft...

Thanks and Cheers,
Andi Walz

___________________________________

Andreas Walz
Research Engineer
Institut=
e of reliable Embedded Systems and Communication Electronics (ivESK)
Off=
enburg University of Applied Sciences, 77652 Offenburg, Germany


_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--94eb2c075f7c29a5ae05463645aa--


From nobody Mon Jan 16 06:59:30 2017
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 3126C129559 for ; Mon, 16 Jan 2017 06:59:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.276
X-Spam-Level: 
X-Spam-Status: No, score=-0.276 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_SBL=1.623, URIBL_SBL_A=0.1] 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 IczDpl1G0s89 for ; Mon, 16 Jan 2017 06:59:27 -0800 (PST)
Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (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 70A6F129557 for ; Mon, 16 Jan 2017 06:59:27 -0800 (PST)
Received: by mail-ua0-x22f.google.com with SMTP id 96so82691350uaq.3 for ; Mon, 16 Jan 2017 06:59:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0xg7K785wQE93gi6uCL0vxW5onUzIc5WWwzWuPMW2UQ=; b=PjGdHcEOB8ot2xDNpc+CBFx2a8iZYlHBaNoKoBz+e6IkqeYtyNRm9CvvFVM8R7P+ny 1YC8GmCgC30JLqJiLZOBJp4FGuFemzWL5rB1lJlTFnbEIBR+hu53rgoiKDQ+7lWPyKiH K34fIXmbUyByIsjx0It/wmQwp7W0XaBjkEq23dFLC9gXB05hSVy/A3sqe3lXl++iYCZ0 9R/JJ8XD4fBf3PCF4GUt8kPog/ZfZxSEno2AlJN2nPRCf6YzwZhyAU0B0PTQVCXucVX0 XVOL71/5snze/hgGnz8KsDuoV6XCXzWzr7BzFizhajBpcLg6eAk+3wUL22Ihd2Wc1yGZ mUdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0xg7K785wQE93gi6uCL0vxW5onUzIc5WWwzWuPMW2UQ=; b=VHZnS6fj2xN1eaI9X9doarQNkFZk6a7ylWgE10BaFft/PGXt45DrqAZiowLL7UOStl Sz5knm10VpCvBfRmVPFDA2veWtHDw5KJzwQlw39TrQDGoB2AOgRhBRPkK9PifBANlDlX q1YF9AWl2gQiXhnsiOp5QreGTuOZDMhe3sgUh/P0J40sfr/kjyHejXStc9ca/TDbl7gC RBQ2J1cZHx8YBMnO5QMT3x7m+mam1axfjVbyUzdPGmc6zH0l9eJHuH711G2Mg57rvhH0 tSiKJcgqis/02Vee3p8hApuaqOwhz15JYEGigzugzHruyJpFnr+K64fpXgER9ceEVOOl 7L5A==
X-Gm-Message-State: AIkVDXJbHNG1mIF5QHJQLjccsiNaWs5YpkYqNVfcn/IKhrphE7PrA2oQU4yQvM4mkT/8PNvOYXuHt/P/eXMOxQ==
X-Received: by 10.176.67.1 with SMTP id k1mr16471326uak.125.1484578766166; Mon, 16 Jan 2017 06:59:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.28.70 with HTTP; Mon, 16 Jan 2017 06:59:25 -0800 (PST)
In-Reply-To: 
References: <587CD98A020000AC00125EEE@gwia2.rz.hs-offenburg.de> 
From: Jayaraghavendran Kuppannan 
Date: Mon, 16 Jan 2017 20:29:25 +0530
Message-ID: 
To: Eric Rescorla 
Content-Type: multipart/alternative; boundary=001a114b5b48ff9efa0546376d75
Archived-At: 
Cc: Jayaraghavendran k , "tls@ietf.org" 
Subject: Re: [TLS] draft-jay-tls-omit-aead-explicit-nonce-extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 16 Jan 2017 14:59:29 -0000

--001a114b5b48ff9efa0546376d75
Content-Type: text/plain; charset=UTF-8

Hi Andreas,

We dropped that draft as there was not much interest in the community for
the same. We will be glad to revive it incase if there is enough interest
in the community.

Regards,
Jay

On Mon, Jan 16, 2017 at 7:05 PM, Eric Rescorla  wrote:

> Andreas,
>
> DTLS 1.3 will behave this way by default, so it would be better to just
> move to 1.3 rather than patching 1.2.
>
> -Ekr
>
>
> On Mon, Jan 16, 2017 at 5:32 AM, Andreas Walz <
> andreas.walz@hs-offenburg.de> wrote:
>
>> Hi all,
>>
>> I stumbled upon an expired draft introducing a new (D)TLS extension to
>> omit explicit nonces in (D)TLS AEAD cipher modes
>> (draft-jay-tls-omit-aead-explicit-nonce-extension). For a number of
>> cipher suites, this would allow to reduce the per-record overhead in (D)TLS
>> by 8 bytes.
>>
>> Is there any interest in breathing new life into that draft? In our
>> scenario (DTLS for a legacy industrial wireless communication system) every
>> single byte counts. That is why we would strongly support reviving this
>> draft...
>>
>> Thanks and Cheers,
>> Andi Walz
>>
>>
>> ___________________________________
>>
>> Andreas Walz
>> Research Engineer
>> Institute of reliable Embedded Systems and Communication Electronics
>> (ivESK)
>> Offenburg University of Applied Sciences, 77652 Offenburg, Germany
>>
>> _______________________________________________
>> 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
>
>

--001a114b5b48ff9efa0546376d75
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Andreas,

We dropped that draft as th=
ere was not much interest in the community for the same. We will be glad to=
 revive it incase if there is enough interest in the community.
<=
br>
Regards,
Jay
=

On Mon, Jan 16, 2017 at 7:05 PM, Eric Rescor=
la <=
ekr@rtfm.com> wrote:
Andreas,

DTLS 1.3 will behave this way by def=
ault, so it would be better to just move to 1.3 rather than patching 1.2.

-Ekr


On Mon, Jan 16=
, 2017 at 5:32 AM, Andreas Walz <andreas.walz@hs-offenburg.de> wrote:
_______________________________________________

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





--001a114b5b48ff9efa0546376d75--


From nobody Mon Jan 16 07:01:57 2017
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 3C36E12955A for ; Mon, 16 Jan 2017 07:01:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.976
X-Spam-Level: 
X-Spam-Status: No, score=-0.976 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_SBL=1.623, URIBL_SBL_A=0.1] 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 kfSnL2RRx-PG for ; Mon, 16 Jan 2017 07:01:53 -0800 (PST)
Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (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 64CB4129549 for ; Mon, 16 Jan 2017 07:01:53 -0800 (PST)
Received: by mail-vk0-x232.google.com with SMTP id k127so28987807vke.0 for ; Mon, 16 Jan 2017 07:01:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=88TiiUSojJehdRsbE9kMADEn5LFKMeSJMSc+lmDo3VA=; b=e6w2/nuDK19glu/8Sx+4WI2iXklNfP2DvZhFvsOvkVS+tqvjlWI/xdWNnm6WFxjP2v 7oG+dMP/2YUzNQrqGwvDkYa8KSlsu5Kq9NiHJu5NWP+77MyallizJGlH0wtAQT8AQ5vT bX3QpPKqUMWLLIlI4lz8vFVHOFo3og67zo407g4jhtF1B8It92CDfUCkKaedw3767ZVS 9BdW79X7boSIRne3o5J29e/WjKk3A/PcVGg/SetU7y3zaykbH0/Zt6wmwoGIeo8Wfjpj FEqbFIjA7F1yNsgR4AD3etu0XsXRFlZzQr3eG4i5EaOevge7BF10tm+cZbYVZszwBinD lQ3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=88TiiUSojJehdRsbE9kMADEn5LFKMeSJMSc+lmDo3VA=; b=iF1lXBNCHnMt3+hVkg6TegU6YyCvvjQCL3qeP/QsQAEAnlRj4ocuSQjuVWfOf9Kbp6 gAZ/7dUhIc4oZI0SFcWQ+hLHJFgyiQNv9kOcotcS57HxQAYo7i9nkqzbYcjfmDRB1TqB z5OY/4/yMaKqkDk6AtjO9hbeWDYVkL0uZPkuLWH8R3w7V5Ljs/sUnbMvfi0MRGmXouvT CWX/GI5VKpmyfczIuqRw+6Rxq9qJMJSbL1N6/2VHtuv6COqu/baYHdrfEqZAV8TFDllv p7m22YORAwsMz9P281BKpxwG914F7IBXf9z5vzqY8a2BzSD2fTxAySLfxEWz4bZ3VlLS YEmA==
X-Gm-Message-State: AIkVDXIjTvl2kYTZFQuWMZpAhTpcPFOMYaY48kSUYFT85eLgaf1MJ9adFRaCytJ4Mc1bU6m0FkigIN1zSwlomg==
X-Received: by 10.31.183.144 with SMTP id h138mr13696905vkf.48.1484578912423;  Mon, 16 Jan 2017 07:01:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.28.70 with HTTP; Mon, 16 Jan 2017 07:01:52 -0800 (PST)
In-Reply-To: 
References: <587CD98A020000AC00125EEE@gwia2.rz.hs-offenburg.de> 
From: Jayaraghavendran Kuppannan 
Date: Mon, 16 Jan 2017 20:31:52 +0530
Message-ID: 
To: Eric Rescorla 
Content-Type: multipart/alternative; boundary=001a1142f230b752e705463776eb
Archived-At: 
Cc: Jayaraghavendran k , "tls@ietf.org" 
Subject: Re: [TLS] draft-jay-tls-omit-aead-explicit-nonce-extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 16 Jan 2017 15:01:55 -0000

--001a1142f230b752e705463776eb
Content-Type: text/plain; charset=UTF-8

Hi Eric,

You had mentioned last time that if the scenario really warranted, we can
define new cipher suites for this rather than defining a new extension. Do
you still think it would be a good idea for us to propose a draft on the
same?

Thanks!

Regards,
Jay

On Mon, Jan 16, 2017 at 7:05 PM, Eric Rescorla  wrote:

> Andreas,
>
> DTLS 1.3 will behave this way by default, so it would be better to just
> move to 1.3 rather than patching 1.2.
>
> -Ekr
>
>
> On Mon, Jan 16, 2017 at 5:32 AM, Andreas Walz <
> andreas.walz@hs-offenburg.de> wrote:
>
>> Hi all,
>>
>> I stumbled upon an expired draft introducing a new (D)TLS extension to
>> omit explicit nonces in (D)TLS AEAD cipher modes
>> (draft-jay-tls-omit-aead-explicit-nonce-extension). For a number of
>> cipher suites, this would allow to reduce the per-record overhead in (D)TLS
>> by 8 bytes.
>>
>> Is there any interest in breathing new life into that draft? In our
>> scenario (DTLS for a legacy industrial wireless communication system) every
>> single byte counts. That is why we would strongly support reviving this
>> draft...
>>
>> Thanks and Cheers,
>> Andi Walz
>>
>>
>> ___________________________________
>>
>> Andreas Walz
>> Research Engineer
>> Institute of reliable Embedded Systems and Communication Electronics
>> (ivESK)
>> Offenburg University of Applied Sciences, 77652 Offenburg, Germany
>>
>> _______________________________________________
>> 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
>
>

--001a1142f230b752e705463776eb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Eric,

You had mentioned last time th=
at if the scenario really warranted, we can define new cipher suites for th=
is rather than defining a new extension. Do you still think it would be a g=
ood idea for us to propose a draft on the same?

Th=
anks!

Regards,
Jay

On Mon, Jan 16, 2017 at 7:0=
5 PM, Eric Rescorla <ekr@rtfm.com> wrote:
Andreas,

DTLS 1.3 will behav=
e this way by default, so it would be better to just move to 1.3 rather tha=
n patching 1.2.

-Ekr


On Mon, Jan 16, 2017 at 5:32 AM, Andreas Walz <andreas.walz@=
hs-offenburg.de> wrote:
Hi all,

I stumbled upon an expired draft i=
ntroducing a new (D)TLS extension to omit explicit nonces in (D)TLS AEAD ci=
pher modes (draft-jay-tls-omit-aead-explicit-nonce-extension). For a n=
umber of cipher suites, this would allow to reduce the per-record overhead =
in (D)TLS by 8 bytes.

Is there any interest in breathing new life in=
to that draft? In our scenario (DTLS for a legacy industrial wireless commu=
nication system) every single byte counts. That is why we would strongly su=
pport reviving this draft...

Thanks and Cheers,
Andi Walz

=

___________________________________

Andreas Walz
Research Engi=
neer
Institute of reliable Embedded Systems and Communication Electronic=
s (ivESK)
Offenburg University of Applied Sciences, 77652 Offenburg, Ger=
many


_______________________________________________

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





--001a1142f230b752e705463776eb--


From nobody Mon Jan 16 07:04:14 2017
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 037C1129560 for ; Mon, 16 Jan 2017 07:04:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 u8odCbohj3vK for ; Mon, 16 Jan 2017 07:04:09 -0800 (PST)
Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::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 2CDD712955A for ; Mon, 16 Jan 2017 07:04:09 -0800 (PST)
Received: by mail-vk0-x22a.google.com with SMTP id k127so29032181vke.0 for ; Mon, 16 Jan 2017 07:04:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8GbTV1M1NRjaeeUzPhXXBsgAncXn5LR8D7Yy67VlgTE=; b=gNPOKTsjWDOo/GRR7M9Hu70B+dtgOAsiH796EVPni6ZFUjjHQyEuRYatxhAn9dAFHJ sobp2XVH24gTPS9X0NUYgbYieNtbrVavDJzA/Qm+Ubyoo+Jr8UDuncKwT66og9SlMI4/ jMh69EdIaAJ5VXsPWS/boEdgvgu4IsiHwqNfq4UaGtsyHmhCZqwmTacWGs/YxI3J2lUI VtyG+BKGbzIsOs6PUUK0EtjKAdJd6JS95909v+YqhVDuQaUlXRvXovQczStHi42PSVmo D8EZzhof6xxc5dSFpmMME9ygVXdiHjy5ddnd65zmersZvAOnLnLrgE4yI30XhBas6rIB s13w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8GbTV1M1NRjaeeUzPhXXBsgAncXn5LR8D7Yy67VlgTE=; b=rkdaBLKWqfpJj+XyNI1YKZddLuY7HRQlA7t4J6iO0c7aUyOp+H76vRyqgUIKCJor7P xj3nlLG7fk1pZg2WGjz/A8frr+xidKaVgsaKMo657faLwrHis1JmSr2S6XicNsaXfI6B RMVrFsGga5/+YCYEvwQTAb4680svBJ7OYk9+563RDUFCJSZRGDU6MrAWCl0fjqkh2dcT IhbDvCRqtBF4OpZHqXqGe4Ckl6yDkG2YwZ5ki/YgD/QaKRu4WAH3hFdt3B7IV5W/iu/u 7BphAdTbeW2RqcFLDixIN0Ag0UdCipeHPp7L72hZgENr4+7nZQGBYxYyzXuTaSYwXIWX 481A==
X-Gm-Message-State: AIkVDXK8OPz7jwtUbBuw7RVPV8R2f5QrxIp4kRwLYrPWoIe24Hq4tWeTQANMG2EcxL+VCb/zHFy5QsMulL4NmQ==
X-Received: by 10.31.158.9 with SMTP id h9mr16094507vke.114.1484579048060; Mon, 16 Jan 2017 07:04:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.28.70 with HTTP; Mon, 16 Jan 2017 07:04:07 -0800 (PST)
In-Reply-To: <587CD706020000AC00125EDA@gwia2.rz.hs-offenburg.de>
References:  <5877AE7B020000AC00125968@gwia2.rz.hs-offenburg.de>  <587CD706020000AC00125EDA@gwia2.rz.hs-offenburg.de>
From: Jayaraghavendran Kuppannan 
Date: Mon, 16 Jan 2017 20:34:07 +0530
Message-ID: 
To: Andreas Walz 
Content-Type: multipart/alternative; boundary=001a11426c06cd03680546377e79
Archived-At: 
Cc: tls@ietf.org
Subject: Re: [TLS] FW: New Version Notification for draft-jay-tls-psk-identity-extension-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 16 Jan 2017 15:04:13 -0000

--001a11426c06cd03680546377e79
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Andreas,

Thanks for the help in reviewing the draft as well as in providing your
usage scenario.

Regards,
Jay

On Mon, Jan 16, 2017 at 6:51 PM, Andreas Walz 
wrote:

> Hi Jay,
>
> our scenario is the following: we are considering a legacy industrial
> communication system with a number of spatially distributed stations.
> Inter-station communication is based on a simple proprietary protocol ove=
r
> a very lean and lossy wireless channel. The channel features 2.4 kbits/s
> and a bit error rate of up to 1E-4. Packets might take several hops until
> they reach their destination.
>
> Despite the aforementioned constraints we would like to use DTLS for
> wireless communication between stations. Therefore, we are investigating
> the potential to minimize the communication overhead of DTLS, both during
> the handshake and for application data datagrams. Every single byte we ca=
n
> save is welcome.
>
> Currently, our scenario does not involve any internet-related
> communication. I could image that because of this IETF's interest in our
> use case is small. We would like to stay standard-compliant though and
> support any plan or effort that helps scaling (D)TLS down without
> sacrificing security.
>
> Thanks and Best Regards,
> Andi Walz
>
>  ___________________________________
>
> Andreas Walz
> Research Engineer
> Institute of reliable Embedded Systems and Communication Electronics
> (ivESK)
> Offenburg University of Applied Sciences, 77652 Offenburg, Germany
>
>
>
> >>> Jayaraghavendran Kuppannan  01/13/17
> 10:27 AM >>>
> Hi Andi,
>
> Thanks a lot for your comments. We will be fixing them.
>
> Right now, we don't have the Git Repository for this draft. Will set it u=
p
> shortly (within a day or two) and send you the link for the updates relat=
ed
> to the typos.
>
> Also, it would be great, if you could elaborate on your scenario, so that
> we can add parts of it in our draft as a part of the use cases.
>
>
> Regards,
> Jay
>
>
>
> On Thu, Jan 12, 2017 at 8:57 PM, Andreas Walz <
> andreas.walz@hs-offenburg.de> wrote:
>
>> Dear all,
>>
>> I read through the draft and I do have some questions/comments which you
>> can find below:
>>
>> -> Section 1, 2nd paragraph: Maybe one could mention explicitly that the
>> new extension allows to do during the Hello phase what would otherwise b=
e
>> done in separate messages in a separate round trip.
>> -> Section 3, 2nd paragraph, under a): it is written "...it checks
>> whether it supports PSK based authentication for its client.". What does
>> "its client" refer to? This is supposed to refer to the ordinary PSK
>> handshake where the server only knows the client's network address at th=
is
>> point in time, isn=E2=80=99t it?
>> -> Section 5.2, 1st paragraph: "Clients supporting this extension should
>> include ...". Is there a reason you don't use "SHOULD"?
>> -> Section 5.2: There is no statement about the order of PSK identities
>> in the extension. Does it mean the order is of no relevance at all? Why =
not
>> allowing the client to express its preferences by means of ordering the
>> items in the list?
>> -> Section 5.3: The fact that abbreviating the handshake only works for
>> pure PSK cipher suites is only mentioned in the third paragraph. Maybe t=
his
>> can be made more explicit somewhere at the beginning of this section (e.=
g.
>> changing the heading to "Abbreviated Handshake for pure PSK Cipher Suite=
s"
>> or the like)?
>> -> Section 5.3, 4th paragraph: the last paragraph only states that for
>> DHE_PSK, RSA_PSK, ECDHE_PSK the server and client key exchange messages =
are
>> still required. It doesn't say anything about whether the presence of th=
e
>> new extension changes the format of these messages. I would expect that
>> server and client key exchange messages omit the PSK_ID part then=E2=80=
=A6or do
>> they keep that part? What is the content then? This should be mentioned
>> somehow, maybe as a separate section?
>> -> Section 5.3: What is a server (client) expected to do if it receives =
a
>> client (server) key exchange message during an abbreviated handshake (wi=
th
>> pure PSK cipher suites)? Maybe mention "During an abbreviated handshake =
the
>> server MUST NOT send a server key exchange message and the client MUST N=
OT
>> send a client key exchange message. Otherwise the receiver MUST abort th=
e
>> handshake with an unexpected_message alert."
>>
>> Some minor comments/typos:
>>
>> -> "PSK" and "pre-shared key" is used alternately in the draft
>> -> Section 2, 2nd paragraph: "Incase" -> "In case"
>> -> Section 5.2, 2nd paragraph: "Please note that, Server MUST include
>> this extension ...". I would change this to "Servers MUST NOT send this
>> extension unless the client sent it in the client hello."
>> -> Section 5.3: A "(" is missing in the diagram below "ServerHello"
>> -> There are some more typos. Do you have a Git repository where I could
>> post a pull request for those? I guess that would be more efficient than
>> listing them here.
>>
>> Thanks and Cheers,
>> Andi Walz
>>
>> ___________________________________
>>
>> Andreas Walz
>> Research Engineer
>> Institute of reliable Embedded Systems and Communication Electronics
>> (ivESK)
>> Offenburg University of Applied Sciences, 77652 Offenburg, Germany
>>
>>
>>
>>
>> >>> Raja ashok  01/11/17 1:31 PM >>>
>> Hi All
>>
>> A new extension is proposed for [D]TLS1.2 and its lower version(not for
>> [D]TLS1.3), to send PSKID in client hello msg instead of client key
>> exchange msg. Using this extension, client can send its list of PSKIDs t=
o
>> server in its hello msg and server can select any one of them and respon=
d
>> in its hello msg.
>> - With the help of this extn, PSK cipher handshake can be completed in
>> 1RTT. Messages exchanged are similar to resumption.
>> - For DHE_PSK, RSA_PSK and ECDHE_PSK ciphers, PSKID in client hello msg
>> gives additional information to server for cipher negotiation. If unknow=
n
>> PSKIDs are present, then server can select any NON PSK cipher or fail at
>> that place only (instead of failing in finished message verification).
>>
>> Already we received interest and review comments from Nikos
>> Mavrogiannopoulos, David Woodhouse and Andreas Walz. Based on that we ha=
ve
>> submitted the 3rd version of this document.
>> I am requesting other members of this group also to look into and provid=
e
>> comments for further improvements.
>>
>> Regards,
>> Raja Ashok V K
>> Huawei Technologies
>> Bangalore, India
>> http://www.huawei.com
>>
>> =E6=9C=AC=E9=82=AE=E4=BB=B6=E5=8F=8A=E5=85=B6=E9=99=84=E4=BB=B6=E5=90=AB=
=E6=9C=89=E5=8D=8E=E4=B8=BA=E5=85=AC=E5=8F=B8=E7=9A=84=E4=BF=9D=E5=AF=86=E4=
=BF=A1=E6=81=AF=EF=BC=8C=E4=BB=85=E9=99=90=E4=BA=8E=E5=8F=91=E9=80=81=E7=BB=
=99=E4=B8=8A=E9=9D=A2=E5=9C=B0=E5=9D=80=E4=B8=AD=E5=88=97=E5=87=BA=E7=9A=84=
=E4=B8=AA=E4=BA=BA=E6=88=96=E7=BE=A4=E7=BB=84=E3=80=82=E7=A6=81
>> =E6=AD=A2=E4=BB=BB=E4=BD=95=E5=85=B6=E4=BB=96=E4=BA=BA=E4=BB=A5=E4=BB=BB=
=E4=BD=95=E5=BD=A2=E5=BC=8F=E4=BD=BF=E7=94=A8=EF=BC=88=E5=8C=85=E6=8B=AC=E4=
=BD=86=E4=B8=8D=E9=99=90=E4=BA=8E=E5=85=A8=E9=83=A8=E6=88=96=E9=83=A8=E5=88=
=86=E5=9C=B0=E6=B3=84=E9=9C=B2=E3=80=81=E5=A4=8D=E5=88=B6=E3=80=81=E6=88=96=
=E6=95=A3=E5=8F=91=EF=BC=89=E6=9C=AC=E9=82=AE=E4=BB=B6=E4=B8=AD
>> =E7=9A=84=E4=BF=A1=E6=81=AF=E3=80=82=E5=A6=82=E6=9E=9C=E6=82=A8=E9=94=99=
=E6=94=B6=E4=BA=86=E6=9C=AC=E9=82=AE=E4=BB=B6=EF=BC=8C=E8=AF=B7=E6=82=A8=E7=
=AB=8B=E5=8D=B3=E7=94=B5=E8=AF=9D=E6=88=96=E9=82=AE=E4=BB=B6=E9=80=9A=E7=9F=
=A5=E5=8F=91=E4=BB=B6=E4=BA=BA=E5=B9=B6=E5=88=A0=E9=99=A4=E6=9C=AC=E9=82=AE=
=E4=BB=B6=EF=BC=81
>> This e-mail and its attachments contain confidential information from
>> HUAWEI, which
>> is intended only for the person or entity whose address is listed above.
>> Any use of the
>> information contained herein in any way (including, but not limited to,
>> total or partial
>> disclosure, reproduction, or dissemination) by persons other than the
>> intended
>> recipient(s) is prohibited. If you receive this e-mail in error, please
>> notify the sender by
>> phone or email immediately and delete it!
>>
>> -----Original Message-----
>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>> Sent: 17 December 2016 04:11
>> To: Raja ashok; Raja ashok; Jayaraghavendran Kuppannan
>> Subject: New Version Notification for draft-jay-tls-psk-identity-
>> extension-02.txt
>>
>>
>> A new version of I-D, draft-jay-tls-psk-identity-extension-02.txt
>> has been successfully submitted by Raja Ashok V K and posted to the IETF
>> repository.
>>
>> Name:        draft-jay-tls-psk-identity-extension
>> Revision:    02
>> Title:        TLS/DTLS PSK Identity Extension
>> Document date:    2016-12-15
>> Group:        Individual Submission
>> Pages:        10
>> URL: https://www.ietf.org/internet-drafts/draft-jay-tls-psk-
>> identity-extension-02.txt
>> Status: https://datatracker.ietf.org/doc/draft-jay-tls-psk-
>> identity-extension/
>> Htmlized: https://tools.ietf.org/html/draft-jay-tls-psk-identity-
>> extension-02
>> Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-jay-tls-psk-
>> identity-extension-02
>>
>> Abstract:
>> Pre-Shared Key (PSK) based Key Exchange Mechanism is primarily used
>> in constrained environments where resource intensive Asymmetric
>> Cryptography cannot be used. In the Internet of Things (IoT)
>> deployments, constrained devices are commonly used for collecting
>> data via sensors for use in home automation, smart energy etc. In
>> this context, DTLS is being considered as the primary protocol for
>> communication security at the application layer and in some cases, it
>> is also being considered for network access authentication.
>>
>> This document provides a specification for a new extension for
>> Optimizing DTLS and TLS Handshake when the Pre-Shared Key (PSK) based
>> Key Exchange is used. This extension is aimed at reducing the number
>> of messages exchanged and the RTT of the TLS & DTLS Handshakes.
>>
>>
>> Hi,
>>
>> I am submitting my 3rd version of our draft(draft-jay-tls-psk-identity-e=
xtension)
>> in TLS working group.
>>
>> Please note that it may take a couple of minutes from the time of
>> submission until the htmlized version and diff are available at
>> tools.ietf.org.
>>
>> The IETF Secretariat
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
>

--001a11426c06cd03680546377e79
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Andreas,

Thanks for the help in revi=
ewing the draft as well as in providing your usage scenario.

=

Regards,
Jay
On Mon, Jan 16, 2017 at 6:51 PM, Andreas Walz <=
span dir=3D"ltr"><andreas.walz@hs-offenburg.de> wrote:
Hi Jay,

our scenario is the following: we are consid=
ering a legacy industrial communication system with a number of spatially d=
istributed stations. Inter-station communication is based on a simple propr=
ietary protocol over a very lean and lossy wireless channel. The channel fe=
atures 2.4 kbits/s and a bit error rate of up to 1E-4. Packets might take s=
everal hops until they reach their destination.

Despite the aforemen=
tioned constraints we would like to use DTLS for wireless communication bet=
ween stations. Therefore, we are investigating the potential to minimize th=
e communication overhead of DTLS, both during the handshake and for applica=
tion data datagrams. Every single byte we can save is welcome.

Curre=
ntly, our scenario does not involve any internet-related communication. I c=
ould image that because of this IETF's interest in our use case is smal=
l. We would like to stay standard-compliant though and support any plan or =
effort that helps scaling (D)TLS down without sacrificing security.

=
Thanks and Best Regards,
Andi Walz
=

=C2=A0___________________________________
Andreas Walz
Research Engineer
Institute of reliable Embedded Syste=
ms and Communication Electronics (ivESK)
Offenburg University of Applied=
 Sciences, 77652 Offenburg, Germany



>>> Jaya=
raghavendran=C2=A0Kuppannan=C2=A0<jayaraghavendran.ietf@gmail.com>=
 01/13/17 10:27 AM >>>
Hi Andi,

Thanks a lot for your comments. We wil=
l be fixing them.

Right now, we don't have the=
 Git Repository for this draft. Will set it up shortly (within a day or two=
) and send you the link for the updates related to the typos.
Also, it would be great, if you could elaborate on your scenari=
o, so that we can add parts of it in our draft as a part of the use cases.=
=C2=A0


Regards,
Jay
=




On Thu, Jan 12, 2017 at 8:57 PM, Andreas Walz <=
andreas.w=
alz@hs-offenburg.de> wrote:
Dear all,

I read through the draft and I do have some q=
uestions/comments which you can find below:

-> Section 1, 2nd par=
agraph: Maybe one could mention explicitly that the new extension allows to=
 do during the Hello phase what would otherwise be done in separate message=
s in a separate round trip.
-> Section 3, 2nd paragraph, under a): it=
 is written "...it checks whether it supports PSK based authentication=
 for its client.". What does "its client" refer to? This is =
supposed to refer to the ordinary PSK handshake where the server only knows=
 the client's network address at this point in time, isn=E2=80=99t it?<=
br>-> Section 5.2, 1st paragraph: "Clients supporting this extensio=
n should include ...". Is there a reason you don't use "SHOUL=
D"?
-> Section 5.2: There is no statement about the order of PSK=
 identities in the extension. Does it mean the order is of no relevance at =
all? Why not allowing the client to express its preferences by means of ord=
ering the items in the list?
-> Section 5.3: The fact that abbreviati=
ng the handshake only works for pure PSK cipher suites is only mentioned in=
 the third paragraph. Maybe this can be made more explicit somewhere at the=
 beginning of this section (e.g. changing the heading to "Abbreviated =
Handshake for pure PSK Cipher Suites" or the like)?
-> Section 5=
.3, 4th paragraph: the last paragraph only states that for DHE_PSK, RSA_PSK=
, ECDHE_PSK the server and client key exchange messages are still required.=
 It doesn't say anything about whether the presence of the new extensio=
n changes the format of these messages. I would expect that server and clie=
nt key exchange messages omit the PSK_ID part then=E2=80=A6or do they keep =
that part? What is the content then? This should be mentioned somehow, mayb=
e as a separate section?
-> Section 5.3: What is a server (client) ex=
pected to do if it receives a client (server) key exchange message during a=
n abbreviated handshake (with pure PSK cipher suites)? Maybe mention "=
During an abbreviated handshake the server MUST NOT send a server key excha=
nge message and the client MUST NOT send a client key exchange message. Oth=
erwise the receiver MUST abort the handshake with an unexpected_message ale=
rt."

Some minor comments/typos:

-> "PSK" an=
d "pre-shared key" is used alternately in the draft
-> Sect=
ion 2, 2nd paragraph: "Incase" -> "In case"
->=
 Section 5.2, 2nd paragraph: "Please note that, Server MUST include th=
is extension ...". I would change this to "Servers MUST NOT send =
this extension unless the client sent it in the client hello."
->=
; Section 5.3: A "(" is missing in the diagram below "Server=
Hello"
-> There are some more typos. Do you have a Git repositor=
y where I could post a pull request for those? I guess that would be more e=
fficient than listing them here.

Thanks and Cheers,
Andi Walz
=

___________________________________

Andreas Walz
Researc=
h Engineer
Institute of reliable Embedded Systems and Communicatio=
n Electronics (ivESK)
Offenburg University of Applied Sciences, 7=
7652 Offenburg, Germany


=C2=A0
<=
br>>>> Raja=C2=A0ashok=C2=A0<raja.ashok@huawei.com> 01/11/17 1:31 P=
M >>>
Hi All

A new extension is proposed for [D]TLS1.2 and its lower vers=
ion(not for [D]TLS1.3), to send PSKID in client hello msg instead of client=
 key exchange msg. Using this extension, client can send its list of PSKIDs=
 to server in its hello msg and server can select any one of them and respo=
nd in its hello msg. 
    - With the help of this extn, PSK cipher hands=
hake can be completed in 1RTT. Messages exchanged are similar to resumption=
.
    - For DHE_PSK, RSA_PSK and ECDHE_PSK ciphers, PSKID in client hell=
o msg gives additional information to server for cipher negotiation. If unk=
nown PSKIDs are present, then server can select any NON PSK cipher or fail =
at that place only (instead of failing in finished message verification).
Already we received interest and review comments from Nikos Mavrogian=
nopoulos, David Woodhouse and Andreas Walz. Based on that we have submitted=
 the 3rd version of this document. 
I am requesting other members of thi=
s group also to look into and provide comments for further improvements.
Regards,
Raja Ashok V K
Huawei Technologies
Bangalore, India<=
br>http://www.huawei.co=
m 

=E6=9C=AC=E9=82=AE=E4=BB=B6=E5=8F=8A=E5=85=B6=E9=99=84=E4=BB=
=B6=E5=90=AB=E6=9C=89=E5=8D=8E=E4=B8=BA=E5=85=AC=E5=8F=B8=E7=9A=84=E4=BF=9D=
=E5=AF=86=E4=BF=A1=E6=81=AF=EF=BC=8C=E4=BB=85=E9=99=90=E4=BA=8E=E5=8F=
=91=E9=80=81=E7=BB=99=E4=B8=8A=E9=9D=A2=E5=9C=B0=E5=9D=80=E4=B8=AD=E5=88=97=
=E5=87=BA=E7=9A=84=E4=B8=AA=E4=BA=BA=E6=88=96=E7=BE=A4=E7=BB=84=E3=80=82=E7=
=A6=81
=E6=AD=A2=E4=BB=BB=E4=BD=95=E5=85=B6=E4=BB=96=E4=BA=BA=E4=BB=A5=
=E4=BB=BB=E4=BD=95=E5=BD=A2=E5=BC=8F=E4=BD=BF=E7=94=A8=EF=BC=88=E5=8C=85=E6=
=8B=AC=E4=BD=86=E4=B8=8D=E9=99=90=E4=BA=8E=E5=85=A8=E9=83=A8=E6=88=96=E9=83=
=A8=E5=88=86=E5=9C=B0=E6=B3=84=E9=9C=B2=E3=80=81=E5=A4=8D=E5=88=B6=E3=
=80=81=E6=88=96=E6=95=A3=E5=8F=91=EF=BC=89=E6=9C=AC=E9=82=AE=E4=BB=B6=E4=B8=
=AD
=E7=9A=84=E4=BF=A1=E6=81=AF=E3=80=82=E5=A6=82=E6=9E=9C=E6=82=A8=E9=
=94=99=E6=94=B6=E4=BA=86=E6=9C=AC=E9=82=AE=E4=BB=B6=EF=BC=8C=E8=AF=B7=
=E6=82=A8=E7=AB=8B=E5=8D=B3=E7=94=B5=E8=AF=9D=E6=88=96=E9=82=AE=E4=BB=B6=E9=
=80=9A=E7=9F=A5=E5=8F=91=E4=BB=B6=E4=BA=BA=E5=B9=B6=E5=88=A0=E9=99=A4=E6=9C=
=AC=E9=82=AE=E4=BB=B6=EF=BC=81
This e-mail and its attachments contain c=
onfidential information from HUAWEI, which 
is intended only for the per=
son or entity whose address is listed above. Any use of the 
information=
 contained herein in any way (including, but not limited to, total or parti=
al 
disclosure, reproduction, or dissemination) by persons other than th=
e intended 
recipient(s) is prohibited. If you receive this e-mail in er=
ror, please notify the sender by 
phone or email immediately and delete =
it!

-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@i=
etf.org] 
Sent: 17 December 2016 04:11
To: Raja ashok; Raja =
ashok; Jayaraghavendran Kuppannan
Subject: New Version Notification for =
draft-jay-tls-psk-identity-extension-02.txt


A new version o=
f I-D, draft-jay-tls-psk-identity-extension-02.txt
has been success=
fully submitted by Raja Ashok V K and posted to the IETF repository.
Name:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0draft-jay-tls-ps=
k-identity-extension
Revision:=C2=A0=C2=A0=C2=A0=C2=A002
Title:=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0TLS/DTLS PSK Identity ExtensionDocument date:=C2=A0=C2=A0=C2=A0=C2=A02016-12-15
Group:=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Individual Submission
Pages:=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A010
URL:            https://www.ietf.org/internet-drafts/draft-jay-t=
ls-psk-identity-extension-02.txt
Status:         https://datatracker.ietf.org/doc/draft-jay-tls-psk-id=
entity-extension/
Htmlized:       https://too=
ls.ietf.org/html/draft-jay-tls-psk-identity-extension-02
D=
iff:           https://www.ietf.org/rfcdiff?=
url2=3Ddraft-jay-tls-psk-identity-extension-02

Abstrac=
t:
   Pre-Shared Key (PSK) based Key Exchange Mechanism is primarily use=
d
   in constrained environments where resource intensive Asymmetric
=
   Cryptography cannot be used. In the Internet of Things (IoT)
   deplo=
yments, constrained devices are commonly used for collecting
   data via=
 sensors for use in home automation, smart energy etc. In
   this contex=
t, DTLS is being considered as the primary protocol for
   communication=
 security at the application layer and in some cases, it
   is also bein=
g considered for network access authentication.

   This document pro=
vides a specification for a new extension for
   Optimizing DTLS and TLS=
 Handshake when the Pre-Shared Key (PSK) based
   Key Exchange is used. =
This extension is aimed at reducing the number
   of messages exchanged =
and the RTT of the TLS & DTLS Handshakes.

                      =
                                                            
Hi, 
I am submitting my 3rd version of our draft(draft-jay-tls-psk-identit=
y-extension) in TLS working group. 

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

The IETF Secretariat

__=
_____________________________________________
TLS mailing list
<=
a href=3D"mailto:TLS@ietf.org" target=3D"_blank">TLS@ietf.org
https://w=
ww.ietf.org/mailman/listinfo/tls
 
______=
_________________________________________
 TLS mailing list
 TLS@ietf.org
 https://ww=
w.ietf.org/mailman/listinfo/tls
 

 





--001a11426c06cd03680546377e79--


From nobody Mon Jan 16 07:10:53 2017
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 272FD129575 for ; Mon, 16 Jan 2017 07:10:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.176
X-Spam-Level: 
X-Spam-Status: No, score=-0.176 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_SBL=1.623, URIBL_SBL_A=0.1] autolearn=no 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 EXnycrjXCv_u for ; Mon, 16 Jan 2017 07:10:51 -0800 (PST)
Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::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 E02BA1294C6 for ; Mon, 16 Jan 2017 07:10:50 -0800 (PST)
Received: by mail-yb0-x234.google.com with SMTP id w194so31089419ybe.0 for ; Mon, 16 Jan 2017 07:10:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BNcZb4d+QNDF3XlXGmgNfYUUcGvEbFXYVbN3Fn3zRb8=; b=pdr0IM8m22QkvlD240TVLWM2d8LxFmrKgaHP+HwqOGF6LP5vMeeENgqX1tSL6fe3cC 1yUZur2vLDFpj0cYOtB7MSCLwCBqmn9SZUbxXiE6Ztdm1YGjWa8OoWaVvEMTwKq/58zX C+jO7aHBN9K+JdPw4McLXMTmKB3luZorPTXsAWdMDS0JP1RarK5UbuVZefo5d29txIwY bxNPuScDefyL8wN1gnTiZPGThw7zrDiY1qu0wa3FUyNwqg2IoJW+6/PzXbZjF46zWeiO WSnQNQPE8LNThXt40mg3wSpYA+uyewu/Pvuots+8yeq2eZPSB/uTNxNS0CRtO1gtc0Jq 0wJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BNcZb4d+QNDF3XlXGmgNfYUUcGvEbFXYVbN3Fn3zRb8=; b=cDcFDkGkIL7Vnh6pCGUvalgBPcYJB1ZxjvfEUif0z2dkGOHOwhiY9tXTCQbjK805CN Q1sF3XYiuN40Uo9EIKWAnLqB189l/rUbxe5YB/bYtec8yeO7Z02BYJQ26zMLior92wCl BZDMDtJvALRr8HdeBbjAhQNj1BJTen9OVvu/RvIckM/wPGgf2BYIYy/D0QEK0Gfyw+D2 mqLyFr3JqMXr1x675v4yHeU9D0j1HhRh2LYl/UzqaK7x9vHXkmNG4I35EDvSMCufdNJU fC3VkPxnBJd59Z2GJsrAvLToqvZARlGmEna0jCia3qVbu6RQLdD0J27L8KEj1bUCWTnC i7Lg==
X-Gm-Message-State: AIkVDXK9y5cHSX8jibucUt7hfjDV41/QATElW272YkCq9Vf/+7ZaEUdCYdR5nEZB1YitjeqkvrGOe3ogVBOl6g==
X-Received: by 10.37.14.69 with SMTP id 66mr4091920ybo.64.1484579449866; Mon, 16 Jan 2017 07:10:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.13.204.80 with HTTP; Mon, 16 Jan 2017 07:10:09 -0800 (PST)
In-Reply-To: 
References: <587CD98A020000AC00125EEE@gwia2.rz.hs-offenburg.de>  
From: Eric Rescorla 
Date: Mon, 16 Jan 2017 07:10:09 -0800
Message-ID: 
To: Jayaraghavendran Kuppannan 
Content-Type: multipart/alternative; boundary=001a113e930cc0730905463796cd
Archived-At: 
Cc: Jayaraghavendran k , "tls@ietf.org" 
Subject: Re: [TLS] draft-jay-tls-omit-aead-explicit-nonce-extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 16 Jan 2017 15:10:52 -0000

--001a113e930cc0730905463796cd
Content-Type: text/plain; charset=UTF-8

On Mon, Jan 16, 2017 at 7:01 AM, Jayaraghavendran Kuppannan <
jayaraghavendran.ietf@gmail.com> wrote:

> Hi Eric,
>
> You had mentioned last time that if the scenario really warranted, we can
> define new cipher suites for this rather than defining a new extension. Do
> you still think it would be a good idea for us to propose a draft on the
> same?
>

No. I think you should move to TLS 1.3 unless it's highly urgent.

-Ekr


>
> Thanks!
>
> Regards,
> Jay
>
> On Mon, Jan 16, 2017 at 7:05 PM, Eric Rescorla  wrote:
>
>> Andreas,
>>
>> DTLS 1.3 will behave this way by default, so it would be better to just
>> move to 1.3 rather than patching 1.2.
>>
>> -Ekr
>>
>>
>> On Mon, Jan 16, 2017 at 5:32 AM, Andreas Walz <
>> andreas.walz@hs-offenburg.de> wrote:
>>
>>> Hi all,
>>>
>>> I stumbled upon an expired draft introducing a new (D)TLS extension to
>>> omit explicit nonces in (D)TLS AEAD cipher modes
>>> (draft-jay-tls-omit-aead-explicit-nonce-extension). For a number of
>>> cipher suites, this would allow to reduce the per-record overhead in (D)TLS
>>> by 8 bytes.
>>>
>>> Is there any interest in breathing new life into that draft? In our
>>> scenario (DTLS for a legacy industrial wireless communication system) every
>>> single byte counts. That is why we would strongly support reviving this
>>> draft...
>>>
>>> Thanks and Cheers,
>>> Andi Walz
>>>
>>>
>>> ___________________________________
>>>
>>> Andreas Walz
>>> Research Engineer
>>> Institute of reliable Embedded Systems and Communication Electronics
>>> (ivESK)
>>> Offenburg University of Applied Sciences, 77652 Offenburg, Germany
>>>
>>> _______________________________________________
>>> 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
>>
>>
>

--001a113e930cc0730905463796cd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On M=
on, Jan 16, 2017 at 7:01 AM, Jayaraghavendran Kuppannan &=
lt;jay=
araghavendran.ietf@gmail.com> wrote:
Hi Eric,

You had mention=
ed last time that if the scenario really warranted, we can define new ciphe=
r suites for this rather than defining a new extension. Do you still think =
it would be a good idea for us to propose a draft on the same?
<=
/blockquote>

No. I think you should move to TLS 1.3 unle=
ss it's highly urgent.

-Ekr
=C2=
=A0

Thanks!

Regards,
Jay

On Mon, Jan 16, 2=
017 at 7:05 PM, Eric Rescorla <ekr@rtfm.com> wrote:
Andreas,

DTLS 1.3 will behave this way by =
default, so it would be better to just move to 1.3 rather than patching 1.2=
.

-Ekr


On Mon, Jan 16, 2017 at 5:32 AM, Andreas Wa=
lz <andreas.walz@hs-offenburg.de> wrote:
Hi all,

I stumbled upon an expired draft intr=
oducing a new (D)TLS extension to omit explicit nonces in (D)TLS AEAD ciphe=
r modes (draft-jay-tls-omit-aead-explicit-nonce-extension). For a numb=
er of cipher suites, this would allow to reduce the per-record overhead in =
(D)TLS by 8 bytes.

Is there any interest in breathing new life into =
that draft? In our scenario (DTLS for a legacy industrial wireless communic=
ation system) every single byte counts. That is why we would strongly suppo=
rt reviving this draft...

Thanks and Cheers,
Andi Walz

___________________________________

Andreas Walz
Research Engineer
Institute of reliable Embed=
ded Systems and Communication Electronics (ivESK)
Offenburg University o=
f Applied Sciences, 77652 Offenburg, Germany


_______________________________________________

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








--001a113e930cc0730905463796cd--


From nobody Mon Jan 16 07:23:16 2017
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 CB4D9129557 for ; Mon, 16 Jan 2017 07:23:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.377
X-Spam-Level: 
X-Spam-Status: No, score=-3.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_SBL=1.623, URIBL_SBL_A=0.1] 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 bYjr7bRq20Ad for ; Mon, 16 Jan 2017 07:23:13 -0800 (PST)
Received: from mail.ottolander.nl (mail.ottolander.nl [176.9.136.165]) by ietfa.amsl.com (Postfix) with ESMTP id 513E4129547 for ; Mon, 16 Jan 2017 07:23:13 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.ottolander.nl (Postfix) with ESMTP id B427F43 for ; Mon, 16 Jan 2017 16:23:12 +0100 (CET)
X-Virus-Scanned: amavisd-new at ottolander.nl
Received: from mail.ottolander.nl ([127.0.0.1]) by localhost (mail.ottolander.nl [127.0.0.1]) (amavisd-new, port 10026) with LMTP id 5kOzHw9L0dyg for ; Mon, 16 Jan 2017 16:23:11 +0100 (CET)
Received: from [192.168.0.60] (leonard-home [87.212.131.169]) by mail.ottolander.nl (Postfix) with ESMTPSA id 6F41042 for ; Mon, 16 Jan 2017 16:23:11 +0100 (CET)
From: Leonard den Ottolander 
To: "tls@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 16 Jan 2017 16:23:10 +0100
Message-ID: <1484580190.5104.6.camel@quad>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.3 (2.32.3-36.1.lj.el6) 
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [TLS] A little room for AES-192 in TLS?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 16 Jan 2017 15:23:15 -0000

L.S.,

Seeing how AES-192 seems to hold up well against related key attacks (at
least the (theoretical) one described in
http://eprint.iacr.org/2009/317) I am rather surprised no AES-192
ciphers have been defined for TLS
(http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4). I feel the cipher is being treated rather stepmotherly.

I do understand that the number of slots for ciphers in the above list
is somewhat limited and additions should be considered carefully.

However, seeing that there are over 60 TLS_DH_* ciphers in that list and
well over 60 CAMMELIAs - to be clear, I am not arguing against the
latter algorithm - the argument not to include AES-192 ciphers in that
list seems somewhat arbitrary.

Also there still seems to be plenty of space available (slots 0x01-55,*
and 0x56,0x01-0xC0,0x00) until this "definition by permutation" approach
can be replaced by a cheaper "definition by slot" where the slots are
chained, i.e. using identifiers for key exchanges, asymmetrical ciphers,
symmetrical ciphers and block modes separately.

Even though I have an interest in mathematics and number theory I do not
claim to have anything more than a rudimentary understanding of the
mathematics involved so please correct me where my insights are wrong.

On superficial reading of http://eprint.iacr.org/2009/317 I grasp that
the higher resistance of AES-192 vs. AES-256 is caused by the fact that
"the key schedule of AES-192 has better diffusion".

Bruce Schneier seems to confirm my suspicion:
https://www.schneier.com/blog/archives/2009/07/another_new_aes.html &
https://www.schneier.com/academic/paperfiles/paper-rijndael.pdf

In the blog he states "The attack exploits the fact that the key
schedule for 256-bit version is pretty lousy -- something we pointed out
in our 2000 paper -- but doesn't extend to AES with a 128-bit key."

He even goes so far as to state "And for new applications I suggest that
people don't use AES-256."

What is causing this better diffusion? Is it the fact that the key size
of AES-192 is not, and the block size is a power of 2? I seem to
remember reading somewhere about DES that the odd key size vs the block
size was considered a strength.

Have the same analyses been done for AES-128? How is AES-128 holding up
against these attacks? (Partially answered by Bruce Schneier's remark above.)

Seeing that we live in "a world of 2^50 keys" and the fact that AES-192
seems to be more robust against related key attacks than AES-256 is I
would like to suggest the inclusion of a few AES-192 ciphers in TLS,
lets say all equivalents of AES-256, possibly reduced by the ciphers
that use hashes weaker than SHA256. Not sure if "DH" and "DH_anon" are
different approaches, but those could be excluded as well, resulting in
something like this list:

TLS_RSA_WITH_AES_192_CBC_SHA256
TLS_DHE_DSS_WITH_AES_192_CBC_SHA256
TLS_DHE_RSA_WITH_AES_192_CBC_SHA256
TLS_RSA_WITH_AES_192_GCM_SHA384
TLS_DHE_RSA_WITH_AES_192_GCM_SHA384
TLS_DHE_DSS_WITH_AES_192_GCM_SHA384
TLS_PSK_WITH_AES_192_GCM_SHA384
TLS_DHE_PSK_WITH_AES_192_GCM_SHA384
TLS_RSA_PSK_WITH_AES_192_GCM_SHA384
TLS_PSK_WITH_AES_192_CBC_SHA384
TLS_DHE_PSK_WITH_AES_192_CBC_SHA384
TLS_RSA_PSK_WITH_AES_192_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_192_CBC_SHA384
TLS_ECDH_ECDSA_WITH_AES_192_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_192_CBC_SHA384
TLS_ECDH_RSA_WITH_AES_192_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_192_GCM_SHA384
TLS_ECDH_ECDSA_WITH_AES_192_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_192_GCM_SHA384
TLS_ECDH_RSA_WITH_AES_192_GCM_SHA384
TLS_ECDHE_PSK_WITH_AES_192_CBC_SHA384
TLS_RSA_WITH_AES_192_CCM
TLS_DHE_RSA_WITH_AES_192_CCM
TLS_RSA_WITH_AES_192_CCM_8
TLS_DHE_RSA_WITH_AES_192_CCM_8
TLS_PSK_WITH_AES_192_CCM
TLS_DHE_PSK_WITH_AES_192_CCM
TLS_PSK_WITH_AES_192_CCM_8
TLS_PSK_DHE_WITH_AES_192_CCM_8
TLS_ECDHE_ECDSA_WITH_AES_192_CCM
TLS_ECDHE_ECDSA_WITH_AES_192_CCM_8

Thank you for considering this request.

Regards,
Leonard den Ottolander.

-- 
mount -t life -o ro /dev/dna /genetic/research




From nobody Mon Jan 16 07:53:01 2017
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 D0C1C12957F for ; Mon, 16 Jan 2017 07:53:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.177
X-Spam-Level: 
X-Spam-Status: No, score=-4.177 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, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_SBL=1.623, URIBL_SBL_A=0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 b0lSMbw6Atpf for ; Mon, 16 Jan 2017 07:52:59 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA0B129557 for ; Mon, 16 Jan 2017 07:52:59 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D004D433417; Mon, 16 Jan 2017 15:52:58 +0000 (GMT)
Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id AC7C243340E; Mon, 16 Jan 2017 15:52:58 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1484581978; bh=wo5+BKmiv/DtFW00pYHY4bnjDGd1LG5YkwAr//F3pyI=; l=3154; h=From:To:Date:References:In-Reply-To:From; b=hiVFjLmUi09K3Ovr3n+m+xxj4kcoTV5qNI2Vb1PKB7jBLuBJjd/ugBwBSweGIpcYA 5P5K4a0fWi/OpZ+bJkBXm7+pJygbINjb42548ovn+fU+2zqgP4j37El/Rxwz3FQ72z 82MM8jpEHBY0pYhMin+5QolcreuEE5iQolcnoyaw=
Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id A69A31FC98; Mon, 16 Jan 2017 15:52:58 +0000 (GMT)
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.1178.4; Mon, 16 Jan 2017 10:52:58 -0500
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.1178.000; Mon, 16 Jan 2017 10:52:58 -0500
From: "Salz, Rich" 
To: Leonard den Ottolander , "tls@ietf.org" 
Thread-Topic: [TLS] A little room for AES-192 in TLS?
Thread-Index: AQHScAx5p6KgDEKgT0au6T9d1jkJFqE7O1DA
Date: Mon, 16 Jan 2017 15:52:58 +0000
Message-ID: <065dfed89fa544efb6e4eeccd3b1ac56@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <1484580190.5104.6.camel@quad>
In-Reply-To: <1484580190.5104.6.camel@quad>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.34.224]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [TLS] A little room for AES-192 in TLS?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 16 Jan 2017 15:53:01 -0000

> I do understand that the number of slots for ciphers in the above list is
> somewhat limited and additions should be considered carefully.
>=20
> However, seeing that there are over 60 TLS_DH_* ciphers in that list and =
well
> over 60 CAMMELIAs - to be clear, I am not arguing against the latter algo=
rithm
> - the argument not to include AES-192 ciphers in that list seems somewhat
> arbitrary.

Think of it in the context of history.  RFC 4132 (Camellia) was in 2005 and=
 DH was part of RFC 2246 in 1999.  Some things have evolved since then. For=
 example, we're moving away from DH (both static and ephemeral) in favor of=
 ECDH. And overall, we are moving away from adding ciphers "just because." =
 The IANA registry is about to change so that each cipher says "required by=
 RFC nnnn" or "no comment" (summarizing).  That is a subtle and important d=
ifference.=20
=20
> Also there still seems to be plenty of space available=20

There are other issue to consider.  For example, some popular software stac=
ks and middleboxes have (had?) trouble with larger clientHello messages, wh=
ich are exacerbated by more ciphers.  And some toolkits, such as OpenSSL my=
 default to offering/accepting "all" ciphers because it is just too hard fo=
r the world to make informed decisions about what is both needed and secure=
.

> Even though I have an interest in mathematics and number theory I do not
> claim to have anything more than a rudimentary understanding of the
> mathematics involved so please correct me where my insights are wrong.

It's always good to state what you don't know.  Seriously.  Thanks for doin=
g this -- it doesn't happen often enough.
=20
> Bruce Schneier seems to confirm my suspicion:
> https://www.schneier.com/blog/archives/2009/07/another_new_aes.html

This paper is eight years old, and focuses on the number of rounds.  Nobody=
 changes the number of rounds of AES; it just doesn't happen.  If you can f=
ind followup research that shows the attacks have gotten better, and that A=
ES 192 is not susceptible to those attack, then I think you might see more =
interest in your proposal.

> to be more robust against related key attacks than AES-256 is I would lik=
e to
> suggest the inclusion of a few AES-192 ciphers in TLS, lets say all equiv=
alents
> of AES-256, possibly reduced by the ciphers that use hashes weaker than
> SHA256. Not sure if "DH" and "DH_anon" are different approaches, but thos=
e
> could be excluded as well, resulting in something like this list:

Proposing more than two dozen new ciphers is not going to get past the WG. =
 I'm only an individual, but I've been around here for some time and think =
that's an accurate view of the likely consensus.  Note that TLS 1.3 defines=
 only three ciphers.

The pendulum is swinging back. We used to define everything in case somethi=
ng broke, but now we try to define as few as possible because of the deploy=
ment issues and, well, we ain't gonna need it.

Hope this helps.
-- =20
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richsalz@jabber.at Twitter: RichSalz


From nobody Mon Jan 16 08:49:57 2017
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 254EC1295A9 for ; Mon, 16 Jan 2017 08:49:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.187
X-Spam-Level: 
X-Spam-Status: No, score=-2.187 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_SBL=1.623, URIBL_SBL_A=0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 fcDyZaACTo6F for ; Mon, 16 Jan 2017 08:49:55 -0800 (PST)
Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEA11293D8 for ; Mon, 16 Jan 2017 08:49:55 -0800 (PST)
Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 1650216D0DC; Mon, 16 Jan 2017 16:49:55 +0000 (GMT)
Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id EAA6216CF01; Mon, 16 Jan 2017 16:49:54 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1484585394; bh=h0UCiku7k3oSw7pE/MG1TM7M3a/UyHEt5snrJstkt10=; l=15144; h=From:To:CC:Date:References:In-Reply-To:From; b=Rb8FkUX7U3v8wtvyVczIoRc5IdTaw1MPCqyAHZt7j9Kd2N5Hn09SKX4n+qYlM1gya FwKPsDLqBBXgmdIL5znXEdGqPN/A5uvwSANaKbo6e8OmlRV0NDA914H3PLbPAldoZn fhsyRe53a3i+fm/Tb3Pt6d/+4N9R0TDr1xe8hkcQ=
Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id C601A1E07C; Mon, 16 Jan 2017 16:49:54 +0000 (GMT)
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 16 Jan 2017 11:49:53 -0500
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.1178.000; Mon, 16 Jan 2017 11:49:54 -0500
From: "Salz, Rich" 
To: Jayaraghavendran Kuppannan , "Eric Rescorla" 
Thread-Topic: [TLS] draft-jay-tls-omit-aead-explicit-nonce-extension
Thread-Index: AQHSb/0KpJW2FT3e/UmbB0d/scClY6E7briAgAAYDwD//8o8cA==
Date: Mon, 16 Jan 2017 16:49:54 +0000
Message-ID: <6f7d18154c9e4f968a6b74e6b5269082@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <587CD98A020000AC00125EEE@gwia2.rz.hs-offenburg.de>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.34.224]
Content-Type: multipart/alternative; boundary="_000_6f7d18154c9e4f968a6b74e6b5269082usma1exdag1mb1msgcorpak_"
MIME-Version: 1.0
Archived-At: 
Cc: Jayaraghavendran k , "tls@ietf.org" 
Subject: Re: [TLS] draft-jay-tls-omit-aead-explicit-nonce-extension
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 16 Jan 2017 16:49:57 -0000

--_000_6f7d18154c9e4f968a6b74e6b5269082usma1exdag1mb1msgcorpak_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QWRkaW5nIG5ldyBjaXBoZXJzIHdvdWxkIHN0aWxsIGludm9sdmUgcGF0Y2hpbmcgZXhpc3Rpbmcg
MS4yIGNvZGUsIHNvIEkgd291bGQgZXhwZWN0IHRoZSBzYW1lIGFuc3dlcjogbW92ZSB0byBEVExT
IDEuMyB3aGVuIGl0cyByZWFkeQ0KDQotLQ0KU2VuaW9yIEFyY2hpdGVjdCwgQWthbWFpIFRlY2hu
b2xvZ2llcw0KTWVtYmVyLCBPcGVuU1NMIERldiBUZWFtDQpJTTogcmljaHNhbHpAamFiYmVyLmF0
IFR3aXR0ZXI6IFJpY2hTYWx6DQoNCkZyb206IEpheWFyYWdoYXZlbmRyYW4gS3VwcGFubmFuIFtt
YWlsdG86amF5YXJhZ2hhdmVuZHJhbi5pZXRmQGdtYWlsLmNvbV0NClNlbnQ6IE1vbmRheSwgSmFu
dWFyeSAxNiwgMjAxNyAxMDowMiBBTQ0KVG86IEVyaWMgUmVzY29ybGENCkNjOiBKYXlhcmFnaGF2
ZW5kcmFuIGs7IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUTFNdIGRyYWZ0LWpheS10bHMt
b21pdC1hZWFkLWV4cGxpY2l0LW5vbmNlLWV4dGVuc2lvbg0KDQpIaSBFcmljLA0KDQpZb3UgaGFk
IG1lbnRpb25lZCBsYXN0IHRpbWUgdGhhdCBpZiB0aGUgc2NlbmFyaW8gcmVhbGx5IHdhcnJhbnRl
ZCwgd2UgY2FuIGRlZmluZSBuZXcgY2lwaGVyIHN1aXRlcyBmb3IgdGhpcyByYXRoZXIgdGhhbiBk
ZWZpbmluZyBhIG5ldyBleHRlbnNpb24uIERvIHlvdSBzdGlsbCB0aGluayBpdCB3b3VsZCBiZSBh
IGdvb2QgaWRlYSBmb3IgdXMgdG8gcHJvcG9zZSBhIGRyYWZ0IG9uIHRoZSBzYW1lPw0KDQpUaGFu
a3MhDQoNClJlZ2FyZHMsDQpKYXkNCg0KT24gTW9uLCBKYW4gMTYsIDIwMTcgYXQgNzowNSBQTSwg
RXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JAcnRmbS5jb20+PiB3cm90ZToN
CkFuZHJlYXMsDQoNCkRUTFMgMS4zIHdpbGwgYmVoYXZlIHRoaXMgd2F5IGJ5IGRlZmF1bHQsIHNv
IGl0IHdvdWxkIGJlIGJldHRlciB0byBqdXN0IG1vdmUgdG8gMS4zIHJhdGhlciB0aGFuIHBhdGNo
aW5nIDEuMi4NCg0KLUVrcg0KDQoNCk9uIE1vbiwgSmFuIDE2LCAyMDE3IGF0IDU6MzIgQU0sIEFu
ZHJlYXMgV2FseiA8YW5kcmVhcy53YWx6QGhzLW9mZmVuYnVyZy5kZTxtYWlsdG86YW5kcmVhcy53
YWx6QGhzLW9mZmVuYnVyZy5kZT4+IHdyb3RlOg0KSGkgYWxsLA0KDQpJIHN0dW1ibGVkIHVwb24g
YW4gZXhwaXJlZCBkcmFmdCBpbnRyb2R1Y2luZyBhIG5ldyAoRClUTFMgZXh0ZW5zaW9uIHRvIG9t
aXQgZXhwbGljaXQgbm9uY2VzIGluIChEKVRMUyBBRUFEIGNpcGhlciBtb2RlcyAoZHJhZnQtamF5
LXRscy1vbWl0LWFlYWQtZXhwbGljaXQtbm9uY2UtZXh0ZW5zaW9uKS4gRm9yIGEgbnVtYmVyIG9m
IGNpcGhlciBzdWl0ZXMsIHRoaXMgd291bGQgYWxsb3cgdG8gcmVkdWNlIHRoZSBwZXItcmVjb3Jk
IG92ZXJoZWFkIGluIChEKVRMUyBieSA4IGJ5dGVzLg0KDQpJcyB0aGVyZSBhbnkgaW50ZXJlc3Qg
aW4gYnJlYXRoaW5nIG5ldyBsaWZlIGludG8gdGhhdCBkcmFmdD8gSW4gb3VyIHNjZW5hcmlvIChE
VExTIGZvciBhIGxlZ2FjeSBpbmR1c3RyaWFsIHdpcmVsZXNzIGNvbW11bmljYXRpb24gc3lzdGVt
KSBldmVyeSBzaW5nbGUgYnl0ZSBjb3VudHMuIFRoYXQgaXMgd2h5IHdlIHdvdWxkIHN0cm9uZ2x5
IHN1cHBvcnQgcmV2aXZpbmcgdGhpcyBkcmFmdC4uLg0KDQpUaGFua3MgYW5kIENoZWVycywNCkFu
ZGkgV2Fseg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkFuZHJl
YXMgV2Fseg0KUmVzZWFyY2ggRW5naW5lZXINCkluc3RpdHV0ZSBvZiByZWxpYWJsZSBFbWJlZGRl
ZCBTeXN0ZW1zIGFuZCBDb21tdW5pY2F0aW9uIEVsZWN0cm9uaWNzIChpdkVTSykNCk9mZmVuYnVy
ZyBVbml2ZXJzaXR5IG9mIEFwcGxpZWQgU2NpZW5jZXMsIDc3NjUyIE9mZmVuYnVyZywgR2VybWFu
eQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVExT
IG1haWxpbmcgbGlzdA0KVExTQGlldGYub3JnPG1haWx0bzpUTFNAaWV0Zi5vcmc+DQpodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RsczxodHRwczovL3VybGRlZmVuc2UucHJv
b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3Rp
bmZvX3RscyZkPUR3TUZhUSZjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmcj00TE0wR2JSMGg5RnZ4
ODZGdHNLSS13Jm09aGJJZHE1RWp4eG14NG56QVY3cXFWc2N4S1FYbVhMNU96WDNsNGxKODBTNCZz
PXlDcnd3WmpEcThQeW1ZVF9JalQ5NVZGYmM1djlRLU9yZEJWc0R4WEFEc1UmZT0+DQoNCg0KX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRMUyBtYWlsaW5n
IGxpc3QNClRMU0BpZXRmLm9yZzxtYWlsdG86VExTQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHM8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu
Y29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb190bHMm
ZD1Ed01GYVEmYz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJnI9NExNMEdiUjBoOUZ2eDg2RnRzS0kt
dyZtPWhiSWRxNUVqeHhteDRuekFWN3FxVnNjeEtRWG1YTDVPelgzbDRsSjgwUzQmcz15Q3J3d1pq
RHE4UHltWVRfSWpUOTVWRmJjNXY5US1PcmRCVnNEeFhBRHNVJmU9Pg0KDQo=

--_000_6f7d18154c9e4f968a6b74e6b5269082usma1exdag1mb1msgcorpak_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg
MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v
c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N
c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1h
cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU
aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5
bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp
bmU7fQ0Kc3Bhbi5tLTYwNTAwNjM0MDIyOTc2NDQzMThob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6
bV8tNjA1MDA2MzQwMjI5NzY0NDMxOGhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28t
c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt
c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5
cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpA
cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu
MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7
fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg
djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm
IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw
IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm
XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw
bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BZGRpbmcgbmV3IGNpcGhl
cnMgd291bGQgc3RpbGwgaW52b2x2ZSBwYXRjaGluZyBleGlzdGluZyAxLjIgY29kZSwgc28gSSB3
b3VsZCBleHBlY3QgdGhlIHNhbWUgYW5zd2VyOiBtb3ZlIHRvIERUTFMgMS4zIHdoZW4gaXRzIHJl
YWR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj4tLSZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNl
bmlvciBBcmNoaXRlY3QsIEFrYW1haSBUZWNobm9sb2dpZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+TWVtYmVyLCBPcGVuU1NMIERldiBUZWFtPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPklNOiByaWNoc2FsekBqYWJiZXIuYXQgVHdpdHRlcjogUmljaFNhbHo8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBp
biAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw
YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh
aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSmF5YXJhZ2hhdmVuZHJhbiBLdXBw
YW5uYW4gW21haWx0bzpqYXlhcmFnaGF2ZW5kcmFuLmlldGZAZ21haWwuY29tXQ0KPGJyPg0KPGI+
U2VudDo8L2I+IE1vbmRheSwgSmFudWFyeSAxNiwgMjAxNyAxMDowMiBBTTxicj4NCjxiPlRvOjwv
Yj4gRXJpYyBSZXNjb3JsYTxicj4NCjxiPkNjOjwvYj4gSmF5YXJhZ2hhdmVuZHJhbiBrOyB0bHNA
aWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtUTFNdIGRyYWZ0LWpheS10bHMtb21p
dC1hZWFkLWV4cGxpY2l0LW5vbmNlLWV4dGVuc2lvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBFcmljLDxvOnA+PC9vOnA+PC9wPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW91IGhhZCBtZW50aW9uZWQgbGFzdCB0aW1lIHRo
YXQgaWYgdGhlIHNjZW5hcmlvIHJlYWxseSB3YXJyYW50ZWQsIHdlIGNhbiBkZWZpbmUgbmV3IGNp
cGhlciBzdWl0ZXMgZm9yIHRoaXMgcmF0aGVyIHRoYW4gZGVmaW5pbmcgYSBuZXcgZXh0ZW5zaW9u
LiBEbyB5b3Ugc3RpbGwgdGhpbmsgaXQgd291bGQgYmUgYSBnb29kIGlkZWEgZm9yIHVzIHRvIHBy
b3Bvc2UgYSBkcmFmdCBvbiB0aGUgc2FtZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SmF5PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgSmFuIDE2LCAyMDE3IGF0
IDc6MDUgUE0sIEVyaWMgUmVzY29ybGEgJmx0OzxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20i
IHRhcmdldD0iX2JsYW5rIj5la3JAcnRmbS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv
cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmRyZWFzLDxvOnA+PC9vOnA+PC9wPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RFRMUyAxLjMgd2lsbCBiZWhhdmUgdGhpcyB3
YXkgYnkgZGVmYXVsdCwgc28gaXQgd291bGQgYmUgYmV0dGVyIHRvIGp1c3QgbW92ZSB0byAxLjMg
cmF0aGVyIHRoYW4gcGF0Y2hpbmcgMS4yLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tRWtyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEphbiAxNiwg
MjAxNyBhdCA1OjMyIEFNLCBBbmRyZWFzIFdhbHogJmx0OzxhIGhyZWY9Im1haWx0bzphbmRyZWFz
LndhbHpAaHMtb2ZmZW5idXJnLmRlIiB0YXJnZXQ9Il9ibGFuayI+YW5kcmVhcy53YWx6QGhzLW9m
ZmVuYnVyZy5kZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND
IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu
LXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SGkgYWxsLDxicj4NCjxicj4NCkkgc3R1bWJs
ZWQgdXBvbiBhbiBleHBpcmVkIGRyYWZ0IGludHJvZHVjaW5nIGEgbmV3IChEKVRMUyBleHRlbnNp
b24gdG8gb21pdCBleHBsaWNpdCBub25jZXMgaW4gKEQpVExTIEFFQUQgY2lwaGVyIG1vZGVzIChk
cmFmdC1qYXktdGxzLW9taXQtYWVhZC1leHBsaWNpdC1ub25jZS1leHRlbnNpb24pLiBGb3IgYSBu
dW1iZXIgb2YgY2lwaGVyIHN1aXRlcywgdGhpcyB3b3VsZCBhbGxvdyB0byByZWR1Y2UgdGhlIHBl
ci1yZWNvcmQgb3ZlcmhlYWQgaW4NCiAoRClUTFMgYnkgOCBieXRlcy48YnI+DQo8YnI+DQpJcyB0
aGVyZSBhbnkgaW50ZXJlc3QgaW4gYnJlYXRoaW5nIG5ldyBsaWZlIGludG8gdGhhdCBkcmFmdD8g
SW4gb3VyIHNjZW5hcmlvIChEVExTIGZvciBhIGxlZ2FjeSBpbmR1c3RyaWFsIHdpcmVsZXNzIGNv
bW11bmljYXRpb24gc3lzdGVtKSBldmVyeSBzaW5nbGUgYnl0ZSBjb3VudHMuIFRoYXQgaXMgd2h5
IHdlIHdvdWxkIHN0cm9uZ2x5IHN1cHBvcnQgcmV2aXZpbmcgdGhpcyBkcmFmdC4uLjxicj4NCjxi
cj4NClRoYW5rcyBhbmQgQ2hlZXJzLDxicj4NCkFuZGkgV2Fsejxicj4NCjxicj4NCjxicj4NCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4
ODgiPjxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJtLTYwNTAwNjM0MDIyOTc2NDQzMThob2VuemIi
PkFuZHJlYXMgV2Fsejwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0ibS02MDUwMDYzNDAyMjk3NjQ0
MzE4aG9lbnpiIj5SZXNlYXJjaCBFbmdpbmVlcjwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0ibS02
MDUwMDYzNDAyMjk3NjQ0MzE4aG9lbnpiIj5JbnN0aXR1dGUgb2YgcmVsaWFibGUgRW1iZWRkZWQg
U3lzdGVtcyBhbmQgQ29tbXVuaWNhdGlvbiBFbGVjdHJvbmljcyAoaXZFU0spPC9zcGFuPjxicj4N
CjxzcGFuIGNsYXNzPSJtLTYwNTAwNjM0MDIyOTc2NDQzMThob2VuemIiPk9mZmVuYnVyZyBVbml2
ZXJzaXR5IG9mIEFwcGxpZWQgU2NpZW5jZXMsIDc3NjUyIE9mZmVuYnVyZywgR2VybWFueTwvc3Bh
bj48L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KVExTIG1haWxpbmcgbGlzdDxicj4NCjxh
IGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5UTFNAaWV0Zi5vcmc8
L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy
bD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb190bHMmYW1wO2Q9RHdN
RmFRJmFtcDtjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmYW1wO3I9NExNMEdiUjBoOUZ2eDg2RnRz
S0ktdyZhbXA7bT1oYklkcTVFanh4bXg0bnpBVjdxcVZzY3hLUVhtWEw1T3pYM2w0bEo4MFM0JmFt
cDtzPXlDcnd3WmpEcThQeW1ZVF9JalQ5NVZGYmM1djlRLU9yZEJWc0R4WEFEc1UmYW1wO2U9IiB0
YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHM8
L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KVExTIG1haWxpbmcgbGlzdDxicj4NCjxh
IGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciPlRMU0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm
PSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3
dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3RscyZhbXA7ZD1Ed01GYVEmYW1wO2M9OTZaYlpa
Y2FNRjR3MEY0anBONkxaZyZhbXA7cj00TE0wR2JSMGg5RnZ4ODZGdHNLSS13JmFtcDttPWhiSWRx
NUVqeHhteDRuekFWN3FxVnNjeEtRWG1YTDVPelgzbDRsSjgwUzQmYW1wO3M9eUNyd3daakRxOFB5
bVlUX0lqVDk1VkZiYzV2OVEtT3JkQlZzRHhYQURzVSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5o
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RsczwvYT48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_6f7d18154c9e4f968a6b74e6b5269082usma1exdag1mb1msgcorpak_--


From nobody Tue Jan 17 04:03:42 2017
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 21246129447 for ; Tue, 17 Jan 2017 04:03:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.198
X-Spam-Level: 
X-Spam-Status: No, score=-5.198 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, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-offenburg.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 shernox3bHY6 for ; Tue, 17 Jan 2017 04:03:39 -0800 (PST)
Received: from mx.hs-offenburg.de (mx.hs-offenburg.de [141.79.11.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB0F91293E9 for ; Tue, 17 Jan 2017 04:03:39 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx.hs-offenburg.de (Postfix) with ESMTP id 97E891687965 for ; Tue, 17 Jan 2017 13:03:37 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-offenburg.de; h=content-type:content-type:mime-version:subject:subject:from :from:date:date:x-mailer:message-id:received:received:received; s=default; t=1484654617; x=1485518618; bh=lNuQFHjURPAz2s+A/iNTv mHSSUQeGGNgMVdWcuQ+k08=; b=u0fTdeV2cyMFMYc8g0ri9pi3LGe7ip5xDCwrX 4b/vHyPwj2dhCksUPH2NmgPg8lfdjszEsYjN+IxpUk92U4w7wDq55LoG82S/vBJd DSyTDDyDgCkEdehjdmj43u28rxRzzVzkQ59OrOBeQBleRf9xg1NgDA52JMUJNvwh peGEVk=
X-Virus-Scanned: amavisd-new at hs-offenburg.de
Received: from mx.hs-offenburg.de ([127.0.0.1]) by localhost (mx.hs-offenburg.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lh2rlV7Gy6lF for ; Tue, 17 Jan 2017 13:03:37 +0100 (CET)
Received: from gwia2.rz.hs-offenburg.de (gwia2.rz.hs-offenburg.de [141.79.10.30]) by mx.hs-offenburg.de (Postfix) with ESMTPS id 188C7168795F for ; Tue, 17 Jan 2017 13:03:37 +0100 (CET)
Received: from gw_dom-gwia2-MTA by gwia2.rz.hs-offenburg.de with Novell_GroupWise; Tue, 17 Jan 2017 13:03:37 +0100
Message-Id: <587E1627020000AC0012612D@gwia2.rz.hs-offenburg.de>
X-Mailer: Novell GroupWise Internet Agent 14.2.1 
Date: Tue, 17 Jan 2017 13:03:35 +0100
From: "Andreas Walz" 
To: 
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part41786A07.0__="
Archived-At: 
Subject: [TLS] ChaCha20+Poly1305 cipher suites with truncted authentication tag?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 17 Jan 2017 12:03:41 -0000

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part41786A07.0__=
Content-Type: multipart/alternative; boundary="=__Part41786A07.1__="

--=__Part41786A07.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hi all,

I know there is some comprehensible reluctance against bloating the TLS =
ecosystem
with even more cipher suites, but still ... have there been considerations =
/ discussions
on adding ChaCha20+Poly1305 cipher suites with truncted authentication =
tags for (D)TLS?

Thanks and Cheers,
Andi Walz

___________________________________

Andreas Walz
Research Engineer
Institute of reliable Embedded Systems and Communication Electronics =
(ivESK)
Offenburg University of Applied Sciences, 77652 Offenburg, Germany



--=__Part41786A07.1__=
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Description: HTML

 =0Abody p =0A{ =0A	margin: 0px; =0A}=0AHi all,

I know there is some comprehensible =
reluctance against bloating the TLS ecosystem
with even more cipher =
suites, but still ... have there been considerations / discussions
on =
adding ChaCha20+Poly1305 cipher suites with truncted authentication tags =
for (D)TLS?

Thanks and Cheers,
Andi Walz

_________________=
__________________

Andreas Walz
Research Engineer
Institute =
of reliable Embedded Systems and Communication Electronics (ivESK)
Offen=
burg University of Applied Sciences, 77652 Offenburg, Germany



--=__Part41786A07.1__=--

--=__Part41786A07.0__=--


From nobody Tue Jan 17 04:10:02 2017
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 D548A12945B for ; Tue, 17 Jan 2017 04:10:00 -0800 (PST)
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 7N8_McFPFfTD for ; Tue, 17 Jan 2017 04:09:59 -0800 (PST)
Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6AF71293E9 for ; Tue, 17 Jan 2017 04:09:58 -0800 (PST)
Received: from pc1 ([2001:2012:127:3e00:b3bf:56a1:a140:6086]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 256bits, ECDHE-RSA-AES256-GCM-SHA384) by zucker.schokokeks.org with ESMTPSA; Tue, 17 Jan 2017 13:09:57 +0100 id 000000000000008A.00000000587E0995.00000EC5
Date: Tue, 17 Jan 2017 13:09:55 +0100
From: Hanno =?UTF-8?B?QsO2Y2s=?= 
To: tls@ietf.org
Message-ID: <20170117130955.7392a685@pc1>
In-Reply-To: <587E1627020000AC0012612D@gwia2.rz.hs-offenburg.de>
References: <587E1627020000AC0012612D@gwia2.rz.hs-offenburg.de>
X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; 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] ChaCha20+Poly1305 cipher suites with truncted authentication tag?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 17 Jan 2017 12:10:01 -0000

On Tue, 17 Jan 2017 13:03:35 +0100
"Andreas Walz"  wrote:

> I know there is some comprehensible reluctance against bloating the
> TLS ecosystem with even more cipher suites, but still ... have there
> been considerations / discussions on adding ChaCha20+Poly1305 cipher
> suites with truncted authentication tags for (D)TLS?

The usual question to answer is: why?

The general reluctance to add new ciphersuites "just because they are
there" is imho very reasonable and in the past TLS got bloated in
complexity far too much because of that.

If you want a new ciphersuite you should have some good arguments why
they offer something that the current ones don't. Ideally these should
be specific. (Aka "Someone could need that for hypothetical situation
XYZ" is not very compelling. "I am developing a widely used product
where this would immensely help for Reasons xyz" is better.)

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

mail/jabber: hanno@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42


From nobody Tue Jan 17 05:05:44 2017
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 820991293E1 for ; Tue, 17 Jan 2017 05:05:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.198
X-Spam-Level: 
X-Spam-Status: No, score=-5.198 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, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-offenburg.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 4YS8CB0nw5XE for ; Tue, 17 Jan 2017 05:05:42 -0800 (PST)
Received: from mx.hs-offenburg.de (mx.hs-offenburg.de [141.79.11.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 859B5128E18 for ; Tue, 17 Jan 2017 05:05:42 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx.hs-offenburg.de (Postfix) with ESMTP id EFCDC168906C for ; Tue, 17 Jan 2017 14:05:40 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-offenburg.de; h=content-type:content-type:mime-version:in-reply-to:references :subject:subject:from:from:date:date:x-mailer:message-id :received:received:received; s=default; t=1484658339; x= 1485522340; bh=1tDzegf511tLvLMLb7mJo23YITybUYC4K0KiGpoe8ZU=; b=d o3xK3udBtbi3F2Ou+4zxB7Gcq2a37SF5ViVoBNnhESPXJl6qyq/ratbn6+5cxjBJ T9or18merOPl52NHpowAMrXOJAyMJgDlkauaS+5oi93u7u2wLNjfIxs7VANAd43g ELX8ovYZlYbw0RXY9cKPL5iefrUYTZ1uGktNJkzxAI=
X-Virus-Scanned: amavisd-new at hs-offenburg.de
Received: from mx.hs-offenburg.de ([127.0.0.1]) by localhost (mx.hs-offenburg.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10zGsQyfY3fX for ; Tue, 17 Jan 2017 14:05:39 +0100 (CET)
Received: from gwia2.rz.hs-offenburg.de (stud.hs-offenburg.de [141.79.10.30]) by mx.hs-offenburg.de (Postfix) with ESMTPS id C9FA11689063 for ; Tue, 17 Jan 2017 14:05:39 +0100 (CET)
Received: from gw_dom-gwia2-MTA by gwia2.rz.hs-offenburg.de with Novell_GroupWise; Tue, 17 Jan 2017 14:05:39 +0100
Message-Id: <587E24B2020000AC0012614B@gwia2.rz.hs-offenburg.de>
X-Mailer: Novell GroupWise Internet Agent 14.2.1 
Date: Tue, 17 Jan 2017 14:05:38 +0100
From: "Andreas Walz" 
To: ,
References: <587E1627020000AC0012612D@gwia2.rz.hs-offenburg.de> <20170117130955.7392a685@pc1>
In-Reply-To: <20170117130955.7392a685@pc1>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartEAD3C1B2.2__="
Archived-At: 
Subject: Re: [TLS] ChaCha20+Poly1305 cipher suites with truncted authentication tag?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 17 Jan 2017 13:05:44 -0000

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartEAD3C1B2.2__=
Content-Type: multipart/alternative; boundary="=__PartEAD3C1B2.3__="

--=__PartEAD3C1B2.3__=
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

I fully support not to add new options / complexity to TLS "just because
they are
there" and I'm not at all doubting the rationale behind this.

Our use case is legacy industrial communication over extremely lean
media (low
bandwidth, high error rate, etc.). We are investigating all directions
of conceivable
optimizations one could apply to DTLS (both configuration and
standardization) in
order to minimize what needs to be sent over the wire (or the ether).
That's why
I expressed interest in a number of old and not so old concepts and
drafts addressing
this.

ChaCha20+Poly1305 seems to have some benefits over AES (e.g. performance
in pure
software). Currently, the only AEAD mode in (D)TLS I'm aware of that
allows
authentication tags shorter than 16 bytes is CCM_8. I guess that there
are other
scenarios -- apart from ours -- where an efficient software-only cipher
(i.e. not
AES-CCM) is desirable but a full-length tag is a bad trade-off between
costs and
benefits. 

I don't have strong intentions to advocate to define yet another cipher
suite for
TLS. I'd rather get a sense of other WG members' interest in that
specific direction.
If there is consensus that there is no point in having ChaCha20+Poly1305
with truncated
tags I'm fine with that. Maybe this would just rebut my assumption that
there could
be broader use for that.

Cheers,
Andi Walz



>>> Hanno Böck  01/17/17 1:10 PM >>>
On Tue, 17 Jan 2017 13:03:35 +0100
"Andreas Walz"  wrote:

> I know there is some comprehensible reluctance against bloating the
> TLS ecosystem with even more cipher suites, but still ... have there
> been considerations / discussions on adding ChaCha20+Poly1305 cipher
> suites with truncted authentication tags for (D)TLS?

The usual question to answer is: why?

The general reluctance to add new ciphersuites "just because they are
there" is imho very reasonable and in the past TLS got bloated in
complexity far too much because of that.

If you want a new ciphersuite you should have some good arguments why
they offer something that the current ones don't. Ideally these should
be specific. (Aka "Someone could need that for hypothetical situation
XYZ" is not very compelling. "I am developing a widely used product
where this would immensely help for Reasons xyz" is better.)

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

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



--=__PartEAD3C1B2.3__=
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Description: HTML

 =0Abody p =0A{ =0A	margin: 0px; =0A}=0AI fully support not to add new options / complexity to =
TLS "just because they are
there" and I'm not at all doubting the =
rationale behind this.

Our use case is legacy industrial communicati=
on over extremely lean media (low
bandwidth, high error rate, etc.). We =
are investigating all directions of conceivable
optimizations one could =
apply to DTLS (both configuration and standardization) in
order to =
minimize what needs to be sent over the wire (or the ether). That's =
why
I expressed interest in a number of old and not so old concepts and =
drafts addressing
this.

ChaCha20+Poly1305 seems to have some =
benefits over AES (e.g. performance in pure
software). Currently, the =
only AEAD mode in (D)TLS I'm aware of that allows
authentication tags =
shorter than 16 bytes is CCM_8. I guess that there are other
scenarios =
-- apart from ours -- where an efficient software-only cipher (i.e. =
not
AES-CCM) is desirable but a full-length tag is a bad trade-off =
between costs and
benefits. 

I don't have strong intentions to =
advocate to define yet another cipher suite for
TLS. I'd rather get a =
sense of other WG members' interest in that specific direction.
If =
there is consensus that there is no point in having ChaCha20+Poly1305 with =
truncated
tags I'm fine with that. Maybe this would just rebut my =
assumption that there could
be broader use for that.

Cheers,
A=
ndi Walz
=

 

&=
gt;>> Hanno B=C3=B6ck <hanno@hboeck.de> 01/17/17 =
1:10 PM >>>
On Tue, 17 Jan 2017 13:03:35 +0100
"Andre=
as Walz" <andreas.walz@hs-offenburg.de> wrote:

> I know =
there is some comprehensible reluctance against bloating the
> TLS =
ecosystem with even more cipher suites, but still ... have there
> =
been considerations / discussions on adding ChaCha20+Poly1305 cipher
>=
; suites with truncted authentication tags for (D)TLS?

The usual =
question to answer is: why?

The general reluctance to add new =
ciphersuites "just because they are
there" is imho very reasonable and =
in the past TLS got bloated in
complexity far too much because of =
that.

If you want a new ciphersuite you should have some good =
arguments why
they offer something that the current ones don't. Ideally =
these should
be specific. (Aka "Someone could need that for hypothetical=
 situation
XYZ" is not very compelling. "I am developing a widely used =
product
where this would immensely help for Reasons xyz" is better.)
=

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

mail/jabber: =
hanno@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

___=
____________________________________________
TLS mailing list
TLS@iet=
f.org
https://www.ietf.org/mailman/listinfo/tls


--=__PartEAD3C1B2.3__=--

--=__PartEAD3C1B2.2__=--


From nobody Tue Jan 17 08:35:15 2017
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 B274D1299BB for ; Tue, 17 Jan 2017 08:35:13 -0800 (PST)
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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 WJ0qJk19aPwE for ; Tue, 17 Jan 2017 08:35:12 -0800 (PST)
Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::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 084C4129970 for ; Tue, 17 Jan 2017 08:35:04 -0800 (PST)
Received: by mail-yw0-x22b.google.com with SMTP id l19so92445598ywc.2 for ; Tue, 17 Jan 2017 08:35:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=KB0xO8Ih7/U65uWw0Rc/wfEp3uZq/LmJRlJadeqfjKA=; b=qcqW3ek9MZW/d5iEKWHiIJV6tYJwYY86ccHI7T0UKWxBsLDK7L2WWGY0XvdM0peitl SscTPLt4EfQofEGx5Luuyt7T27DdSs1GMcFZMpukj55mAdhf50DZVljDYXNhtWq+JGee OAogSmIGmYeafR/+4ONeuwknQXFKJdHTb/L1ylmZQnWZBRvneUcdUhV//q3n0Rpbu2iP 5d2YfaD8+Eag7TLVD7CFF9oVMJFVs73LH9XlQslXWTNTLtp4p4nGX6+7S9ILaxMAEK7w Gaah7CnX5ICVjYHfoTPAQKh3uUJdqsyFKoxDCmSjLRywbPGk7DoN56uNe7z1q6wX9UQz qYjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=KB0xO8Ih7/U65uWw0Rc/wfEp3uZq/LmJRlJadeqfjKA=; b=kaQ1PIBWLwsKth2FBqz2jiS1ypEsE3W3RUwvYQSbL26BOHyB/WQY21F7e7R8GOHp3F JSHsdpPLzx6ncdowHcVz4tJYlQMyOxvlbvszs0+SBpeMP0UNi+DCnGNc2knXOcZdjqow bfi3awdRZElA8Fsctu/rwzGhmF0CsF8QQFgIbxhjy8OMd/2hOnYTtDoHTcCSpLZVbiFv fWMqZYclZwh1NLWf12H+X3hRGswLXCCRNhPrt2i47Di7WQGzPMVShUGk0FmpyYrMXMme 9MifF/xwaolIyVNoFeop2PSjuA+UwAJ28aSAQVRTmtg+lELFwDwFOgGgKon8DeKA08jg lpLw==
X-Gm-Message-State: AIkVDXKO6DJXCAMhRfmzJWc33XSLYOJpQG9tfoyglx646iU9zH8YQAQM6SgYAQR3xPjWqmCLP9IkfFEvlOQMKg==
X-Received: by 10.129.52.6 with SMTP id b6mr29036943ywa.113.1484670904015; Tue, 17 Jan 2017 08:35:04 -0800 (PST)
MIME-Version: 1.0
Received: by 10.13.235.136 with HTTP; Tue, 17 Jan 2017 08:35:03 -0800 (PST)
In-Reply-To: <587E24B2020000AC0012614B@gwia2.rz.hs-offenburg.de>
References: <587E1627020000AC0012612D@gwia2.rz.hs-offenburg.de> <20170117130955.7392a685@pc1> <587E24B2020000AC0012614B@gwia2.rz.hs-offenburg.de>
From: Watson Ladd 
Date: Tue, 17 Jan 2017 08:35:03 -0800
Message-ID: 
To: Andreas Walz 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] ChaCha20+Poly1305 cipher suites with truncted authentication tag?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 17 Jan 2017 16:35:13 -0000

On Tue, Jan 17, 2017 at 5:05 AM, Andreas Walz
 wrote:
> I fully support not to add new options / complexity to TLS "just because
> they are
> there" and I'm not at all doubting the rationale behind this.
>
> Our use case is legacy industrial communication over extremely lean media
> (low
> bandwidth, high error rate, etc.). We are investigating all directions of
> conceivable
> optimizations one could apply to DTLS (both configuration and
> standardization) in
> order to minimize what needs to be sent over the wire (or the ether). Tha=
t's
> why
> I expressed interest in a number of old and not so old concepts and draft=
s
> addressing
> this.
>
> ChaCha20+Poly1305 seems to have some benefits over AES (e.g. performance =
in
> pure
> software). Currently, the only AEAD mode in (D)TLS I'm aware of that allo=
ws
> authentication tags shorter than 16 bytes is CCM_8. I guess that there ar=
e
> other
> scenarios -- apart from ours -- where an efficient software-only cipher
> (i.e. not
> AES-CCM) is desirable but a full-length tag is a bad trade-off between co=
sts
> and
> benefits.
>
> I don't have strong intentions to advocate to define yet another cipher
> suite for
> TLS. I'd rather get a sense of other WG members' interest in that specifi=
c
> direction.
> If there is consensus that there is no point in having ChaCha20+Poly1305
> with truncated
> tags I'm fine with that. Maybe this would just rebut my assumption that
> there could
> be broader use for that.

Have you read the Poly1305 paper and the TLS spec carefully? The
effect of tag truncation is far worse than it would be for other
suits, although the Chacha20-Poly1305 uses a different
r each time to ameliorate this if I understand correctly. Careful
analysis is required.

>
> Cheers,
> Andi Walz
>
>
>
>>>> Hanno B=C3=B6ck  01/17/17 1:10 PM >>>
> On Tue, 17 Jan 2017 13:03:35 +0100
> "Andreas Walz"  wrote:
>
>> I know there is some comprehensible reluctance against bloating the
>> TLS ecosystem with even more cipher suites, but still ... have there
>> been considerations / discussions on adding ChaCha20+Poly1305 cipher
>> suites with truncted authentication tags for (D)TLS?
>
> The usual question to answer is: why?
>
> The general reluctance to add new ciphersuites "just because they are
> there" is imho very reasonable and in the past TLS got bloated in
> complexity far too much because of that.
>
> If you want a new ciphersuite you should have some good arguments why
> they offer something that the current ones don't. Ideally these should
> be specific. (Aka "Someone could need that for hypothetical situation
> XYZ" is not very compelling. "I am developing a widely used product
> where this would immensely help for Reasons xyz" is better.)
>
> --
> 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
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



--=20
"Man is born free, but everywhere he is in chains".
--Rousseau.


From nobody Tue Jan 17 13:46:39 2017
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 4A94D129495 for ; Tue, 17 Jan 2017 13:46:37 -0800 (PST)
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] 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 Kgswt4Gmd5zr for ; Tue, 17 Jan 2017 13:46:34 -0800 (PST)
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 8350D129422 for ; Tue, 17 Jan 2017 13:46:34 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4A1A0300278 for ; Tue, 17 Jan 2017 16:36:18 -0500 (EST)
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 rNckJ5WjKfph for ; Tue, 17 Jan 2017 16:36:16 -0500 (EST)
Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 7C636300157; Tue, 17 Jan 2017 16:36:16 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_D756CE78-FE32-4E68-8EE0-11A1AF7144B1"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley 
In-Reply-To: 
Date: Tue, 17 Jan 2017 16:46:31 -0500
Message-Id: <227A868E-7430-48BB-B65B-F15E1CCC39AB@vigilsec.com>
References:  <5877AE7B020000AC00125968@gwia2.rz.hs-offenburg.de>  <587CD706020000AC00125EDA@gwia2.rz.hs-offenburg.de> 
To: Jayaraghavendran Kuppannan 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: IETF TLS 
Subject: Re: [TLS] New Version Notification for draft-jay-tls-psk-identity-extension-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 17 Jan 2017 21:46:37 -0000

--Apple-Mail=_D756CE78-FE32-4E68-8EE0-11A1AF7144B1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I think there are two very different scenarios where an identity needs =
to be associated with an external PSK, that is a PSK that is not =
produced by a previous handshake.  This draft only addresses one of =
them, and I would rather see a way forward that considers both.

This draft considers the scenario where the PSK is used to avoid the use =
of (EC)DHE altogether.

The other scenario is where the PSK is combined with the (EC)DHE shared =
secret as protection against a quantum computer.  In this case the =
identity associated with the PSK must be compatible with the identity in =
the certificate.  We have not had any discussion about the meaning of =
compatible in this context.  I believe the TLS WG wants to wrap up the =
core TLS 1.3 specification before delving into that topic.

For that reason, I think that the topic of this draft must also wait =
until the core TLS 1.3 specification is in the hands of the IESG.

Russ



From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20
Sent: 17 December 2016 04:11
To: Raja ashok; Raja ashok; Jayaraghavendran Kuppannan
Subject: New Version Notification for =
draft-jay-tls-psk-identity-extension-02.txt


A new version of I-D, draft-jay-tls-psk-identity-extension-02.txt
has been successfully submitted by Raja Ashok V K and posted to the IETF =
repository.

Name:        draft-jay-tls-psk-identity-extension
Revision:    02
Title:        TLS/DTLS PSK Identity Extension
Document date:    2016-12-15
Group:        Individual Submission
Pages:        10
URL: =
https://www.ietf.org/internet-drafts/draft-jay-tls-psk-identity-extension-=
02.txt
Status: =
https://datatracker.ietf.org/doc/draft-jay-tls-psk-identity-extension/
Htmlized: =
https://tools.ietf.org/html/draft-jay-tls-psk-identity-extension-02
Diff: =
https://www.ietf.org/rfcdiff?url2=3Ddraft-jay-tls-psk-identity-extension-0=
2

Abstract:
Pre-Shared Key (PSK) based Key Exchange Mechanism is primarily used
in constrained environments where resource intensive Asymmetric
Cryptography cannot be used. In the Internet of Things (IoT)
deployments, constrained devices are commonly used for collecting
data via sensors for use in home automation, smart energy etc. In
this context, DTLS is being considered as the primary protocol for
communication security at the application layer and in some cases, it
is also being considered for network access authentication.

This document provides a specification for a new extension for
Optimizing DTLS and TLS Handshake when the Pre-Shared Key (PSK) based
Key Exchange is used. This extension is aimed at reducing the number
of messages exchanged and the RTT of the TLS & DTLS Handshakes.


Hi,=20

I am submitting my 3rd version of our =
draft(draft-jay-tls-psk-identity-extension) in TLS working group.=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.

The IETF Secretariat


--Apple-Mail=_D756CE78-FE32-4E68-8EE0-11A1AF7144B1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


I think there are two very different scenarios =
where an identity needs to be associated with an external PSK, that is a =
PSK that is not produced by a previous handshake.  This draft only =
addresses one of them, and I would rather see a way forward that =
considers both.

This draft considers the =
scenario where the PSK is used to avoid the use of (EC)DHE =
altogether.

The other scenario is where the PSK =
is combined with the (EC)DHE shared secret as protection against a =
quantum computer.  In this case the identity associated with the =
PSK must be compatible with the identity in the certificate.  We =
have not had any discussion about the meaning of compatible in this =
context.  I believe the TLS WG wants to wrap up the core TLS 1.3 =
specification before delving into that =
topic.

For that reason, I think that the topic =
of this draft must also wait until the core TLS 1.3 specification is in =
the hands of the =
IESG.

Russ


<=
div class=3D"m_7556633250156720846h5">From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
Sent: 17 =
December 2016 04:11
To: Raja ashok; Raja ashok; Jayaraghavendran =
Kuppannan
Subject: New Version Notification for =
draft-jay-tls-psk-identity-extension-02.txt


A new =
version of I-D, draft-jay-tls-psk-identity-extension-02.txt
has =
been successfully submitted by Raja Ashok V K and posted to the IETF =
repository.

Name:        dr=
aft-jay-tls-psk-identity-extension
Revision:   &nbs=
p;02
Title:        TLS/DTLS =
PSK Identity Extension
Document =
date:    2016-12-15
Group:    &=
nbsp;   Individual =
Submission
Pages:        10
=
URL:            https://www.ietf.org/internet-drafts/draft-jay-tls-=
psk-identity-extension-02.txt
Status:         https://datatracker.ietf.org/doc/draft-jay-tls-psk-=
identity-extension/
Htmlized:       https://tools.ietf.org/html/draft-jay-tls-psk-ident=
ity-extension-02
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-jay-tls-p=
sk-identity-extension-02

Abstract:
   Pre-Shared Key =
(PSK) based Key Exchange Mechanism is primarily used
   in =
constrained environments where resource intensive Asymmetric
   =
Cryptography cannot be used. In the Internet of Things (IoT)
   =
deployments, constrained devices are commonly used for collecting
   =
data via sensors for use in home automation, smart energy etc. In
   =
this context, DTLS is being considered as the primary protocol for
   =
communication security at the application layer and in some cases, =
it
   is also being considered for network access =
authentication.

   This document provides a specification for a =
new extension for
   Optimizing DTLS and TLS Handshake when the =
Pre-Shared Key (PSK) based
   Key Exchange is used. This extension is =
aimed at reducing the number
   of messages exchanged and the RTT of =
the TLS & DTLS Handshakes.

                                   =
                                               
Hi, 

I am =
submitting my 3rd version of our =
draft(draft-jay-tls-psk-identity-extension) in TLS working group. =


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

=
=

--Apple-Mail=_D756CE78-FE32-4E68-8EE0-11A1AF7144B1--


From nobody Wed Jan 18 07:40:03 2017
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 7778A129452 for ; Wed, 18 Jan 2017 07:40:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.401
X-Spam-Level: 
X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, 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 9La-IGp4kxMv for ; Wed, 18 Jan 2017 07:40:00 -0800 (PST)
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 199ED12945D for ; Wed, 18 Jan 2017 07:40:00 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 01766B80190; Wed, 18 Jan 2017 07:39:59 -0800 (PST)
To: tim@dierks.org, ekr@rtfm.com, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, sean+ietf@sn3rd.com, joe@salowey.net
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Message-Id: <20170118154000.01766B80190@rfc-editor.org>
Date: Wed, 18 Jan 2017 07:40:00 -0800 (PST)
Archived-At: 
Cc: tls@ietf.org, nmalykh@gmail.com, rfc-editor@rfc-editor.org
Subject: [TLS] [Technical Errata Reported] RFC5246 (4912)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 18 Jan 2017 15:40:01 -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_search.php?rfc=5246&eid=4912

--------------------------------------
Type: Technical
Reported by: Nikolai Malykh 

Section: A.4.1

Original Text
-------------
   SignatureAndHashAlgorithm
    supported_signature_algorithms<2..2^16-1>;


Corrected Text
--------------
   SignatureAndHashAlgorithm
    supported_signature_algorithms<2..2^16-2>;


Notes
-----
Error in last sentence. See errata ID 2865.

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 Wed Jan 18 14:13:08 2017
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 B005A12959E; Wed, 18 Jan 2017 14:13:05 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.40.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148477758571.2016.8358831483357416024.idtracker@ietfa.amsl.com>
Date: Wed, 18 Jan 2017 14:13:05 -0800
Archived-At: 
Cc: tls@ietf.org
Subject: [TLS] I-D Action: draft-ietf-tls-grease-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 18 Jan 2017 22:13:06 -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 of the IETF.

        Title           : Applying GREASE to TLS Extensibility
        Author          : David Benjamin
	Filename        : draft-ietf-tls-grease-00.txt
	Pages           : 8
	Date            : 2017-01-18

Abstract:
   This document describes GREASE (Generate Random Extensions And
   Sustain Extensibility), a mechanism to prevent extensibility failures
   in the TLS ecosystem.  It reserves a set of TLS protocol values that
   may be advertised by clients to ensure servers correctly handle
   unknown values.


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-tls-grease-00


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 Jan 18 14:16:20 2017
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 CCA77129587 for ; Wed, 18 Jan 2017 14:16:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.898
X-Spam-Level: 
X-Spam-Status: No, score=-5.898 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.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham 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 i1HXeq7haCoE for ; Wed, 18 Jan 2017 14:16:17 -0800 (PST)
Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 460BA1294A3 for ; Wed, 18 Jan 2017 14:16:17 -0800 (PST)
Received: by mail-qt0-x230.google.com with SMTP id x49so34387985qtc.2 for ; Wed, 18 Jan 2017 14:16:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=dSxlyO8PJ8GfO9Yyrrrv3SCxDOiSE1KSk4VcmcAuQz4=; b=AYO3dsL20k/3eEsKA/OeKEoQ2iO3ujyZ2hKoy+5x8u++o3BeJzVX/jcILRZS0NQeS+ Yg1Rexr+0aClwp1kRba3ClxfaQ+cXRHdTwhINmlyeJTym8ZULTvcdWny1FSyCVCRVoXp rp0TRb2lmfxJoqrjaW9+K7T6bjui72nRPyLbg=
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=dSxlyO8PJ8GfO9Yyrrrv3SCxDOiSE1KSk4VcmcAuQz4=; b=nm4gSioyzSgMLrsNHu5TzQvi2AuG/OQNudnbvak6+JKyydB4DAPy5EJ2golBxp7g6K 9UPjv5kGXz3Tr2/tufwHFzP2H8DyUZyET1vb5EvtWI1sJFwiFsLS14co0KsCALH2rEpq IYeRzkECrHfil55ewwwdO1g/DivKcr2WQY1qgkBxOdiejzlMmWx+FEUDDo7B3UEu2fss 9vVxMV+7LuPsMVbtJI9cbR0dp4zHZ+Uq8UMDC2fALxn5lr1motuajy59B+zFhctxyHxV f0mUhQA60addOq326wBEVWvix5MZiojzc/Xpe03il7qbSUsdVuXa5d29oXVteuED/zts I4OA==
X-Gm-Message-State: AIkVDXL50UmNBF/XuzMlmULYmZ0Kc+6dogsHUHXQ0agvT4k0Brnia6sbkVye0KJ5dEi7lsHCkqv7IEwJRKZWmKXB
X-Received: by 10.237.35.1 with SMTP id h1mr5395744qtc.276.1484777776274; Wed, 18 Jan 2017 14:16:16 -0800 (PST)
MIME-Version: 1.0
References: <4C288CF8-28D4-4E03-914C-08D238C84292@sn3rd.com>
In-Reply-To: <4C288CF8-28D4-4E03-914C-08D238C84292@sn3rd.com>
From: David Benjamin 
Date: Wed, 18 Jan 2017 22:16:05 +0000
Message-ID: 
To: Sean Turner , "" 
Content-Type: multipart/alternative; boundary=001a1135c7b2ed5ff9054665c3f4
Archived-At: 
Subject: Re: [TLS] adopted: draft-davidben-tls-grease
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 18 Jan 2017 22:16:19 -0000

--001a1135c7b2ed5ff9054665c3f4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Done. Let me know if I did any of that incorrectly.

(Sorry about the delay. I've been some combination of suffering from a
cold, on vacation, or at conferences for the past month---usually more than
one at a time!)

On Tue, Jan 3, 2017 at 8:59 AM Sean Turner  wrote:

I appears that we=E2=80=99ve got enough consensus/interest to adopt
draft-davidben-tls-grease based on this thread:
https://mailarchive.ietf.org/arch/msg/tls/NnNMMRygtXzPXMg3d6WlSBrsZ7w

David,

Please submit draft-ietf-tls-grease at your earliest convenience.  I=E2=80=
=99ll set
up a tlswg repo in just a sec.

Thanks!

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

--001a1135c7b2ed5ff9054665c3f4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Done. Let me know if =
I did any of that incorrectly.

(Sorry about the delay. I've been some combination of sufferi=
ng from a cold, on vacation, or at conferences for the past month---usually=
 more than one at a time!)

On Tue, Jan 3, 2017 at 8:59 AM Sean Turner <sean@sn3rd.com>=
; wrote:
I appears that we=E2=80=99ve got enough consensus/interest to adopt dra=
ft-davidben-tls-grease based on this thread:

https://mai=
larchive.ietf.org/arch/msg/tls/NnNMMRygtXzPXMg3d6WlSBrsZ7w



David,



Please submit draft-ietf-tls-grease at your earliest convenience.=C2=A0 I=
=E2=80=99ll set up a tlswg repo in just a sec.



Thanks!



J&S

_______________________________________________

TLS mailing list

TLS@i=
etf.org

https://www.ietf.org/mailman/listinfo/t=
ls




--001a1135c7b2ed5ff9054665c3f4--


From nobody Wed Jan 18 14:49:31 2017
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 561AF129518 for ; Wed, 18 Jan 2017 14:49:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.898
X-Spam-Level: 
X-Spam-Status: No, score=-5.898 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.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham 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 XJ1G35fN7pvI for ; Wed, 18 Jan 2017 14:49:29 -0800 (PST)
Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 953BD1295BD for ; Wed, 18 Jan 2017 14:49:28 -0800 (PST)
Received: by mail-qt0-x22a.google.com with SMTP id v23so36142637qtb.0 for ; Wed, 18 Jan 2017 14:49:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=gpW94e3F8FUVW3BchPh5wJMTVfemXd7Gfjx25sLU9tc=; b=DreOtgY322ZunKqqpawlX0YR42Yn70PehfcW5i2Zjp8a2hHg/pLDLIrdUbACYdP7pn xN1X+dknEzF83UKUkUiI6v00uoepMA0Yj8r9aXv1F3TXwEkRfiZ1q32XNjLrVBM2S/H4 cNwNmQXoUwgs2KOP440+/qMgqDJNiC0gR0soc=
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=gpW94e3F8FUVW3BchPh5wJMTVfemXd7Gfjx25sLU9tc=; b=q3A9r2SSlW9dd/P4wsI9iViCefn0lxjMlXFJJhzEsRZtGIPD8vpLG0y86K5Vr3Xxsv 0iAjwBb3kyCBy7Gl8rreutffkxUQEqQvVolmyhAEXwoe1w8bbGg/V12ozKpnNCD8Pkpw pTYqS6tPfFVtNVhYCYdiFUQQ4ZCRAmiOgNA/vjUIWeg0pcpOHEXqp+LIiDhh2Nlaa95R evAL6PmhTEyyvhB3rgYdGyWTgSAXA7fXKGHg6s68E7lLw5Im1GjfFsWJhjACuRaf1SRQ GFc7usXTTuZaxwIypqzafobelf+4MEAmy84YSJbe032emsmwxlnMzf1bZswNRQh4rGfV 306Q==
X-Gm-Message-State: AIkVDXLNV1j02JWaOQr9jQAKuOKxUlp0x+yp5w9h6+nYMbGV3TwtKKbBARLLkKRaKlhIudS6btvoir8qOjpChmE6
X-Received: by 10.200.49.41 with SMTP id g38mr5051283qtb.175.1484779767380; Wed, 18 Jan 2017 14:49:27 -0800 (PST)
MIME-Version: 1.0
From: David Benjamin 
Date: Wed, 18 Jan 2017 22:49:17 +0000
Message-ID: 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a113a2bec9b049a0546663a58
Archived-At: 
Subject: [TLS] GREASE and TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 18 Jan 2017 22:49:30 -0000

--001a113a2bec9b049a0546663a58
Content-Type: text/plain; charset=UTF-8

So, having uploaded draft-ietf-tls-grease-00, I would now like to rewrite
large chunks of it. The draft is currently defined for TLS 1.2, but it
probably makes sense to order it after TLS 1.3.

TLS 1.3 also adds a many new extension points, and we can expect new TLS
1.3 implementations popping up in the near future, so having the ecosystem
primed against intolerance bugs would be great.

(As a happy anecdote, Chrome is currently GREASEing bits of its draft TLS
1.3 implementation. This worked beautifully. There was a draft TLS 1.3
server implementation that broke on unknown versions in supported_versions
and unknown groups in key_shares. Interop testing against a normal client
did not notice. When they tried interop testing against Chrome, the bugs
were caught and fixed.)

I was thinking of making the following changes:

- Cite TLS 1.3 instead of TLS 1.2.

- Add some text to use the same code point pattern for TLS 1.3
signature_algorithms.

- Add some text to suggest advertising GREASE values in key_shares if
advertised in supported_groups. [This already caught a bug.]

- Add some text to use the same code point pattern for
supported_versions. [This already caught a bug.]

- Generalize the extensions text to allow for CertificateRequest and
NewSessionTicket extensions sent by the server. [This might have caught a
bug had it not been caught by other means first.]

Do people agree with this plan?

I've left out psk_key_exchange_modes. It would be nice to GREASE that too,
but it uses u8 rather than u16 values. The natural generalization is to
reserve 0x?a instead of 0x?a?a. But then we lose 16 out of 256 code points,
rather than 16 out of 65536 code points. Do people feel this is an
acceptable tradeoff? Perhaps a smaller pattern? Or is this not worth
bothering with?

David

--001a113a2bec9b049a0546663a58
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


So, having uploaded draft-ietf-tls-grease-00, I would now =
like to rewrite large chunks of it. The draft is currently defined for TLS =
1.2, but it probably makes sense to order it after TLS 1.3.

<=
div>TLS 1.3 also adds a many new extension points, and we can expect new TL=
S 1.3 implementations popping up in the near future, so having the ecosyste=
m primed against intolerance bugs would be great.

=
(As a happy anecdote, Chrome is currently GREASEing bits of its draft TLS 1=
.3 implementation. This worked beautifully. There was a draft TLS 1.3 serve=
r implementation that broke on unknown versions in supported_versions and u=
nknown groups in key_shares. Interop testing against a normal client did no=
t notice.=C2=A0When they tried interop testing against Chrome, the bugs wer=
e caught and fixed.)

I was thinking of making the =
following changes:

- Cite TLS 1.3 instead of TLS 1=
.2.

- Add some text to use the same code poin=
t pattern for TLS 1.3 signature_algorithms.

- Add some text to suggest advertising=
 GREASE values in key_shares if advertised in supported_groups. [This alrea=
dy caught a bug.]

- Add some text to use the s=
ame code point pattern for supported_versions.=C2=A0[This already caught a =
bug.]

- Generalize the extensions text to all=
ow for CertificateRequest and NewSessionTicket extensions sent by the serve=
r. [This might have caught a bug had it not been caught by other means firs=
t.]

Do people agree with this plan?

I've left out psk_key_exchange_modes. It would be=
 nice to GREASE that too, but it uses u8 rather than u16 values. The natura=
l generalization is to reserve 0x?a instead of 0x?a?a. But then we lose 16 =
out of 256 code points, rather than 16 out of 65536 code points. Do people =
feel this is an acceptable tradeoff? Perhaps a smaller pattern? Or is this =
not worth bothering with?

David


--001a113a2bec9b049a0546663a58--


From nobody Wed Jan 18 17:11:27 2017
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 1157B1295A6 for ; Wed, 18 Jan 2017 17:11:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.2
X-Spam-Level: 
X-Spam-Status: No, score=-5.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iij.ad.jp
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 EFnT99kyuKOr for ; Wed, 18 Jan 2017 17:11:25 -0800 (PST)
Received: from omgo.iij.ad.jp (mo900.iij.ad.jp [202.232.31.76]) (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 8BEFE129442 for ; Wed, 18 Jan 2017 17:04:53 -0800 (PST)
DKIM-Signature: v=1;a=rsa-sha256;c=relaxed/simple;d=iij.ad.jp;h=Date: Message-Id:To:Subject:From:In-Reply-To:References:Mime-Version:Content-Type: Content-Transfer-Encoding; i=kazu@iij.ad.jp; s=omgo2; t=1484787891; x=1485997491;  bh=kAmIQOV0GbFL48sx9++tlDsWbGPC33OZUiAesqnWyTo=; b=h4LHiC1a2XB0oYu2ZR/IEWNB4Oz w0f2CPScN/6RYn3QzD9mfBlDw0t/bcC/Wh7BTqehCRaY6OuZFb4rasHEI2AYVw/pnvpQqIj+fEbXW dWcjL7I+CFactcvh8u7MNDuN/nyBVLQ6amipBvwnCDAyRCERL3XOc57zdXzuGvLlDhMPfK9BkRarw 6/3N7Rh3Ju1b2+IiKYJINf92fdC5rgeskH59xyz4rm7y8prC3qA3oX+g08aJSlItT/V1xNspNf8iL ZP5InI591mrzgCw5jSW29DNrqPu9arNqRB/CtlJy3JjzQk4AHMfjf/McI7rH8Ujv5p/szyO7mjyhd erK7v1w==;
Received: by omgo.iij.ad.jp (mo900) id v0J14phV007968; Thu, 19 Jan 2017 10:04:51 +0900
X-MXL-Hash: 588010b378a07495-cd4df106fb58335ce881caa2c3437ea2974a2374
Date: Thu, 19 Jan 2017 10:04:52 +0900 (JST)
Message-Id: <20170119.100452.59119300306420768.kazu@iij.ad.jp>
To: tls@ietf.org
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) 
In-Reply-To: 
References: 
X-Mailer: Mew version 6.7 on Emacs 25.1 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [TLS] GREASE and TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 19 Jan 2017 01:11:26 -0000

Hi David,

> I was thinking of making the following changes:
> 
> - Cite TLS 1.3 instead of TLS 1.2.
> 
> - Add some text to use the same code point pattern for TLS 1.3
> signature_algorithms.
> 
> - Add some text to suggest advertising GREASE values in key_shares if
> advertised in supported_groups. [This already caught a bug.]
> 
> - Add some text to use the same code point pattern for
> supported_versions. [This already caught a bug.]
> 
> - Generalize the extensions text to allow for CertificateRequest and
> NewSessionTicket extensions sent by the server. [This might have caught a
> bug had it not been caught by other means first.]
> 
> Do people agree with this plan?

I agree.

Should we also add grease values for key_share?

--Kazu


From nobody Wed Jan 18 17:15:36 2017
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 D480A1295D1 for ; Wed, 18 Jan 2017 17:15:34 -0800 (PST)
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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 uN1Kqd2T8kn1 for ; Wed, 18 Jan 2017 17:15:33 -0800 (PST)
Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 9F3FD129442 for ; Wed, 18 Jan 2017 17:15:33 -0800 (PST)
Received: by mail-qt0-x22d.google.com with SMTP id l7so41899836qtd.1 for ; Wed, 18 Jan 2017 17:15:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gbuk2HJj6w6FmEEDAkdUf5LXu/KFqOwJ6UkyftJOJzI=; b=q6ZqZyCrX4XGiI8cgwamSW2nOWwK7BWwo4JW/wIp14g6zRHuXtMhdesIicfo7pi6eU tPrPCxaCduL9e91/sdqN5If+1XnTi1BXg8vrH2x1aQVEPt7jWwzS4iciSUG0+OUZ9Qcm VfUOU7jk2jLLv6/BpMqtDvN6jIYqyTCnVbHpDU9U6TbIQVyHbtjG2CmDhiaXdWUyj3nz pfv9WngG75P0vWhp3xIvPM91iN1QVr6BmzcD8SvII3wNnIxjjiQyQlAOCvOzmKgJuQh/ 70k1g3rNueL50PvXVSR4vhSuuqb5CSzOm3Ls49EzS5RIV2578tb/hFDF6kA41WpcYuEV peGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gbuk2HJj6w6FmEEDAkdUf5LXu/KFqOwJ6UkyftJOJzI=; b=C3+JkH292Ew5Oo/UPT3ODyW9ru28ZNslkZEycDyZpqTXKz85uRkKS0Eb7oSJubXpYy x+II8T37Hc22Dc7h/VmnSSr9c4iQ/2ZcyIkNst9oJZzoZZwtubH+p4/1VHlhrFc3q5C1 utdA3KkWOprvyRlGEn13qdXKkRHQ+t81K8XRC8QWX8zXjJ2hF+zvx6/Sun3CIFcWCpFs 5CrOEPtAUJ1ZNYRHImrb3QFF5+oVr91t/UUOit/1WKJIKNlDLlhAXxKjt/D6GfwGvPdA z89453L2mhE4fAlrHaWkfI3O6P04Es8BCE3uptivnij78K22CAdRApKo0qT37eUqn2tO dWNw==
X-Gm-Message-State: AIkVDXKmJam0PaIaYsiLHPTf7FdUR5yIWSWjNDCWSba0zxVbHE00J9afl6hs/VbZtiUXzzPDCFVbgPNfAJKhlA==
X-Received: by 10.55.99.85 with SMTP id x82mr5465874qkb.147.1484788532785; Wed, 18 Jan 2017 17:15:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.19.112 with HTTP; Wed, 18 Jan 2017 17:15:32 -0800 (PST)
In-Reply-To: <20170119.100452.59119300306420768.kazu@iij.ad.jp>
References:  <20170119.100452.59119300306420768.kazu@iij.ad.jp>
From: Martin Thomson 
Date: Thu, 19 Jan 2017 14:15:32 +1300
Message-ID: 
To: Kazu Yamamoto 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] GREASE and TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 19 Jan 2017 01:15:35 -0000

On 19 January 2017 at 14:04, Kazu Yamamoto  wrote:
> Should we also add grease values for key_share?

supported_groups code points should cover that, but if you are asking
if we should spend bytes on sending shares for bogus groups, that's a
question I don't have an opinion on.  I guess that you *could*, but
whether the document should recommend it ....


From nobody Wed Jan 18 17:24:48 2017
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 F07C21295DF for ; Wed, 18 Jan 2017 17:24:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.898
X-Spam-Level: 
X-Spam-Status: No, score=-5.898 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.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham 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 l1g8NM-U0pxi for ; Wed, 18 Jan 2017 17:24:45 -0800 (PST)
Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 471381295A6 for ; Wed, 18 Jan 2017 17:24:45 -0800 (PST)
Received: by mail-qt0-x22f.google.com with SMTP id l7so42223942qtd.1 for ; Wed, 18 Jan 2017 17:24:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=A5e+X7PVUh5ZRAcpAbxneKgZVBkuN4RYrTGBrP0g2yc=; b=C1wuC+cv48bjEpJu7YekZ+Qp1fh2tNh/ku7mY9KKNejt+1JfOBAnQX3gsIWjJ9Zsyy SfnNOS85TYyLM2LmW9ZJm2KMgq6xXRcHyip/fOyD2s3dg9r/GtX12BLlZRTfrkEnBUV2 mWm8bdFfbEKVu/z1u+602KCHgJaHVX7HSQZ7Q=
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=A5e+X7PVUh5ZRAcpAbxneKgZVBkuN4RYrTGBrP0g2yc=; b=qhL27ceWWzFc5wMZumLGtYPqruXZMu0JtrY+n0kTFSfdRR+xql9sBnp980TpCChca5 jRhU0Cx8MPsD78+5TRNpo11ekidZbMTdaf9KCzHyBLBfowZ9nP/0RolrWToxTNT/LO9p 546eY+DubLL+TCP6LnMq3Lz7x3Z2Ij8ojdRVgz1Xa1yUmFfbFhmblcrA3cyarXZYXtXl zndzgDNfNWMSLFT/maDWd4VuSNaz4Q3yja1JyXcj8Zox2AFtYi7tTR5HM6IlEhYtyUh2 Fijbryt7V3sX41qyeMFRYHkTMmzaSiPF/ZCnqMFIWpEjlLAYrMVbc4EQ0zClKVctNg5r dvdw==
X-Gm-Message-State: AIkVDXJcCRZqShh9UeIow9ZEE9x568WDCI5fml0IEYaN/sHGF9U6XHW5WVch4aArlayrJenz2gJoggcOiqmwMvpE
X-Received: by 10.237.34.116 with SMTP id o49mr5471222qtc.122.1484789084163; Wed, 18 Jan 2017 17:24:44 -0800 (PST)
MIME-Version: 1.0
References:  <20170119.100452.59119300306420768.kazu@iij.ad.jp> 
In-Reply-To: 
From: David Benjamin 
Date: Thu, 19 Jan 2017 01:24:33 +0000
Message-ID: 
To: Martin Thomson , Kazu Yamamoto 
Content-Type: multipart/alternative; boundary=001a113e7bf6edfa8d05466865f9
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] GREASE and TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 19 Jan 2017 01:24:47 -0000

--001a113e7bf6edfa8d05466865f9
Content-Type: text/plain; charset=UTF-8

On Wed, Jan 18, 2017 at 8:15 PM Martin Thomson 
wrote:

On 19 January 2017 at 14:04, Kazu Yamamoto  wrote:
> Should we also add grease values for key_share?

supported_groups code points should cover that, but if you are asking
if we should spend bytes on sending shares for bogus groups, that's a
question I don't have an opinion on.  I guess that you *could*, but
whether the document should recommend it ....


That's what we do in Chrome/BoringSSL. We send one fake NamedGroup at the
front of supported_groups and then put it in key_shares with a one-byte
fake KeyShareEntry.

It costs five bytes total and, having already caught a bug with it, seems
valuable. It ensures that servers are capable of skipping over an unknown
KeyShareEntry and don't just go for the first one. But, document-wise, I
was expecting to just use MAY for everything rather than expressing much
opinion.

(Front is because presumably if we add a new NamedGroup, it'd be because we
like it more than our current ones rather than less! So it's more important
that that edge continue working.)

David

--001a113e7bf6edfa8d05466865f9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Wed, Jan 18, 2017 a=
t 8:15 PM Martin Thomson <martin.thomson@gmail.com> wrote:=

On 1=
9 January 2017 at 14:04, Kazu Yamamoto <kazu@iij.ad.jp> wrote:

> Should we also add grease values for key_share?



supported_groups code points should cover that, but if you are asking

if we should spend bytes on sending shares for bogus groups, that's a
question I don't have an opinion on.=C2=A0 I guess that you *could*, bu=
t

whether the document should recommend it ....

<=
div dir=3D"ltr" class=3D"gmail_msg">
That's what we do in Chrome/BoringSSL. We send o=
ne fake NamedGroup at the front of supported_groups and then put it in key_=
shares with a one-byte fake KeyShareEntry.
It costs five bytes to=
tal and, having already caught a bug with it, seems valuable. It ensures th=
at servers are capable of skipping over an unknown KeyShareEntry and don=
9;t just go for the first one. But, document-wise, I was expecting to just =
use MAY for everything rather than expressing much opinion.

(Fron=
t is because presumably if we add a new NamedGroup, it'd be because we =
like it more than our current ones rather than less! So it's more impor=
tant that that edge continue working.)

David


--001a113e7bf6edfa8d05466865f9--


From nobody Wed Jan 18 19:00:38 2017
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 C1ACB12940F for ; Wed, 18 Jan 2017 19:00:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.2
X-Spam-Level: 
X-Spam-Status: No, score=-5.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iij.ad.jp
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 b3euSaME2fY7 for ; Wed, 18 Jan 2017 19:00:34 -0800 (PST)
Received: from omgo.iij.ad.jp (mo901.iij.ad.jp [202.232.31.77]) (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 869B9129435 for ; Wed, 18 Jan 2017 19:00:34 -0800 (PST)
DKIM-Signature: v=1;a=rsa-sha256;c=relaxed/simple;d=iij.ad.jp;h=Date: Message-Id:To:Subject:From:In-Reply-To:References:Mime-Version:Content-Type: Content-Transfer-Encoding; i=kazu@iij.ad.jp; s=omgo2; t=1484794832; x=1486004432;  bh=FTl47zvhb9I4fdc5FqWVyYANyU/wYH/+stgOyy5lDvw=; b=VDSTBr7AYz8zeumBOeLfSHW7UYo w4UH+JRU3pq2o4shcnDaS1GOb5u7zPLx9hh1fTOtqUWOVfDL1Bgt45Fsih1T0GTFXtWQrUCSZtMyz 6THpEvJsZu84C4sZqA2wM9SOkhJjMCZ2mC27xm6gbc6jq4SpzmiJdZKz9DisOU4gmeJS43HexXWvE bkIy86o2gSzPYt5hlzC06K0vqw1pByZADpwPe0S4CzkXM9lJRdaqQ/eDzMwy7bUgTUe2e/nH/w3rF Rf7F3UlWx3n3LLiznru7+yrHJg4X8LHR73sA7acip7LelkRXEacu1tSykLFbchS89gVLKn6OE46fT RAtRCug==;
Received: by omgo.iij.ad.jp (mo901) id v0J30Wjq017884; Thu, 19 Jan 2017 12:00:32 +0900
X-MXL-Hash: 58802bd05c7279bb-ecd1723b971b9f1b0e96eefe6022b9639b0d0305
Date: Thu, 19 Jan 2017 12:00:31 +0900 (JST)
Message-Id: <20170119.120031.1228095559979874241.kazu@iij.ad.jp>
To: tls@ietf.org
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) 
In-Reply-To: 
References: <20170119.100452.59119300306420768.kazu@iij.ad.jp>  
X-Mailer: Mew version 6.7 on Emacs 25.1 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [TLS] GREASE and TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 19 Jan 2017 03:00:37 -0000

> That's what we do in Chrome/BoringSSL. We send one fake NamedGroup at the
> front of supported_groups and then put it in key_shares with a one-byte
> fake KeyShareEntry.
> 
> It costs five bytes total and, having already caught a bug with it, seems
> valuable. It ensures that servers are capable of skipping over an unknown
> KeyShareEntry and don't just go for the first one. But, document-wise, I
> was expecting to just use MAY for everything rather than expressing much
> opinion.

OK.

--Kazu


From nobody Thu Jan 19 11:31:35 2017
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 D8688129407 for ; Thu, 19 Jan 2017 11:31:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.899
X-Spam-Level: 
X-Spam-Status: No, score=-5.899 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_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 5JeSP9nVVkrq for ; Thu, 19 Jan 2017 11:31:32 -0800 (PST)
Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id A08A812943B for ; Thu, 19 Jan 2017 11:31:32 -0800 (PST)
Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id EC8DF433422; Thu, 19 Jan 2017 19:31:31 +0000 (GMT)
Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id D691E43340A; Thu, 19 Jan 2017 19:31:31 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1484854291; bh=tep+ex4bVDLxS/RXEojnfU4AWSB4DWuDVQm+zBOPX/Y=; l=2370; h=To:References:From:Date:In-Reply-To:From; b=veSeVmjEtekKFVI2HL7tMGMNTSFubss+Il2ALLfJyEMuI55Hb/a914Rf+yYdDItRe doF05nhd0vfSafaKc6Iih4Q9dOO+2m55c+i6FROKjCLykwCSY0qe96UmYeJAl6de3z OI7I8JjT5usLj35IUYsjpPb0lORX355p86DsRCmw=
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id A88591FC8B; Thu, 19 Jan 2017 19:31:31 +0000 (GMT)
To: David Benjamin , "tls@ietf.org" 
References: 
From: Benjamin Kaduk 
X-Enigmail-Draft-Status: N1110
Message-ID: <92dcf6c4-60b9-c6d9-ed3d-fa9e8624d995@akamai.com>
Date: Thu, 19 Jan 2017 13:31:31 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------E61DD20A88237A884200FE62"
Archived-At: 
Subject: Re: [TLS] GREASE and TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 19 Jan 2017 19:31:34 -0000

This is a multi-part message in MIME format.
--------------E61DD20A88237A884200FE62
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit

On 01/18/2017 04:49 PM, David Benjamin wrote:
>
> Do people agree with this plan?
>

Yes :)

> I've left out psk_key_exchange_modes. It would be nice to GREASE that
> too, but it uses u8 rather than u16 values. The natural generalization
> is to reserve 0x?a instead of 0x?a?a. But then we lose 16 out of 256
> code points, rather than 16 out of 65536 code points. Do people feel
> this is an acceptable tradeoff? Perhaps a smaller pattern? Or is this
> not worth bothering with?
>

I feel like we're unlikely to come up with enough modes that we run out
of space, so it is probably okay to grease it.  But I would be okay if
people wanted to not do so, too.

-Ben

--------------E61DD20A88237A884200FE62
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    On 01/18/2017 04:49 PM, David Benjamin wrote:

    

      
      


        

          
Do people agree with this plan?

          


          

        

      

    

    

    Yes :)

    

    

      

        

          
I've left out psk_key_exchange_modes. It would be nice to
            GREASE that too, but it uses u8 rather than u16 values. The
            natural generalization is to reserve 0x?a instead of 0x?a?a.
            But then we lose 16 out of 256 code points, rather than 16
            out of 65536 code points. Do people feel this is an
            acceptable tradeoff? Perhaps a smaller pattern? Or is this
            not worth bothering with?

          

        

      

    

    

    I feel like we're unlikely to come up with enough modes that we run
    out of space, so it is probably okay to grease it. But I would be
    okay if people wanted to not do so, too.

    

    -Ben

  


--------------E61DD20A88237A884200FE62--


From nobody Thu Jan 19 11:35:27 2017
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 418E212949B for ; Thu, 19 Jan 2017 11:35:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 uXONIb8RQrnL for ; Thu, 19 Jan 2017 11:35:25 -0800 (PST)
Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::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 D63EE12951A for ; Thu, 19 Jan 2017 11:35:24 -0800 (PST)
Received: by mail-yw0-x233.google.com with SMTP id v200so46335684ywc.3 for ; Thu, 19 Jan 2017 11:35:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ASssdOOfv6FkKEHjRwas8LekuHldAz7G1r/EWRxiX5U=; b=rlHBzeIEumhSjJGiHR7kxL8hWfAvVz6F+cbQM0paBCkf2BbJ0j/1nYmmJrfJiCdU6N hL4pmMPdlzKA5yQt+0VeB7vG7khXErqwvY1J1c73wkm8xR6wOQr7FJmo3/PwNbkqtW87 omUeILUmPh8xVOQ5ybUvr+/+cNyLBr9Ewk2xdo+IpCWzslxtC5EUcoKvBka3/N1XdzFE otWksOEq5d3ljouXv+Vox6OuFDgq5W8/kddRiNIKpsK4TEXkwU2ctoldd2Y6hGmrIKoO COsCRvKAx8oOGVz4tfwrHBpYxjr2hsqzz5UCQX8hStA2BNAAr0ekNvnka5PwGex7QglS npOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ASssdOOfv6FkKEHjRwas8LekuHldAz7G1r/EWRxiX5U=; b=ERp7EUjZLTi5QTOSqqVC7MtZBhVDDa1VxaRyydas81YHRN0uKMyqJA7uGkIU/2qQue x6UI5chRMGlAMXyf1mfzsheFudeEvf43FuY8c0k2RHpFNjbxXyrK8PZSOnHWH2h3NPyF jswfKUe1iQouRA4aV7kSYaujvq3KOzNhZ6BA2C9qnX1sxJDoYD8KoYd3hPCAkspVxkk1 TmMDLTlJpI5GkDhpPd7r+G7JZ8Vrj4H5l7A5DhOb4cPeL98/zTgS9F+8leqHkcEeqwkj 7kBYQEqd4UI78nV9GtXMkeCLSTmnOBvKHercLAZgbGogc11xJc2o3FYGabqH5on/ZxTm qQBw==
X-Gm-Message-State: AIkVDXJfy338IA9KM6DxbAAjCpA8nvodsf2QUcovsr6O198gl70KUMk81HeZnVVkJSY9CB6v2PX7JjNSdWZXJw==
X-Received: by 10.129.125.84 with SMTP id y81mr7997731ywc.120.1484854524239; Thu, 19 Jan 2017 11:35:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.13.204.80 with HTTP; Thu, 19 Jan 2017 11:34:43 -0800 (PST)
In-Reply-To: <92dcf6c4-60b9-c6d9-ed3d-fa9e8624d995@akamai.com>
References:  <92dcf6c4-60b9-c6d9-ed3d-fa9e8624d995@akamai.com>
From: Eric Rescorla 
Date: Thu, 19 Jan 2017 11:34:43 -0800
Message-ID: 
To: Benjamin Kaduk 
Content-Type: multipart/alternative; boundary=001a114928ba7612b8054677a266
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] GREASE and TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 19 Jan 2017 19:35:26 -0000

--001a114928ba7612b8054677a266
Content-Type: text/plain; charset=UTF-8

Grease away.

On Thu, Jan 19, 2017 at 11:31 AM, Benjamin Kaduk  wrote:

> On 01/18/2017 04:49 PM, David Benjamin wrote:
>
>
> Do people agree with this plan?
>
>
> Yes :)
>
> I've left out psk_key_exchange_modes. It would be nice to GREASE that too,
> but it uses u8 rather than u16 values. The natural generalization is to
> reserve 0x?a instead of 0x?a?a. But then we lose 16 out of 256 code points,
> rather than 16 out of 65536 code points. Do people feel this is an
> acceptable tradeoff? Perhaps a smaller pattern? Or is this not worth
> bothering with?
>
>
> I feel like we're unlikely to come up with enough modes that we run out of
> space, so it is probably okay to grease it.  But I would be okay if people
> wanted to not do so, too.
>
> -Ben
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--001a114928ba7612b8054677a266
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Grease away.

On Thu, Jan 19, 2017 at 11:31 AM, Benjamin Kaduk <bkaduk=
@akamai.com> wrote:

 =20
   =20
 =20
  

    On 01/18/2017 04:49 PM, David Benjamin wrote:

    

     =20
      


        

          
Do people agree with this plan?

          


          

        

      

    

    

    Yes :)

    

    

      

        

          
I've left out psk_key_exchange_modes. It would be nice t=
o
            GREASE that too, but it uses u8 rather than u16 values. The
            natural generalization is to reserve 0x?a instead of 0x?a?a.
            But then we lose 16 out of 256 code points, rather than 16
            out of 65536 code points. Do people feel this is an
            acceptable tradeoff? Perhaps a smaller pattern? Or is this
            not worth bothering with?

          

        

      

    

    

    I feel like we're unlikely to come up with enough modes that we run
    out of space, so it is probably okay to grease it.=C2=A0 But I would be
    okay if people wanted to not do so, too.

    

    -Ben

  



_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--001a114928ba7612b8054677a266--


From nobody Fri Jan 20 09:43:32 2017
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 E2FE91294B4 for ; Fri, 20 Jan 2017 09:43:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.59
X-Spam-Level: 
X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_HK_NAME_DR=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 scd_AI70ku_I for ; Fri, 20 Jan 2017 09:43:28 -0800 (PST)
Received: from claranet-outbound-smtp03.uk.clara.net (claranet-outbound-smtp03.uk.clara.net [195.8.89.36]) by ietfa.amsl.com (Postfix) with ESMTP id 4440212943D for ; Fri, 20 Jan 2017 09:43:27 -0800 (PST)
Received: from host86-161-67-142.range86-161.btcentralplus.com ([86.161.67.142]:46512 helo=[192.168.1.64]) by relay03.mail.eu.clara.net (relay.clara.net [81.171.239.33]:10465) with esmtpa (authdaemon_plain:drh) id 1cUdDe-0003f6-CH  for tls@ietf.org (return-path ); Fri, 20 Jan 2017 17:43:23 +0000
To: "tls@ietf.org list" 
From: Dr Stephen Henson 
Message-ID: 
Date: Fri, 20 Jan 2017 17:43:21 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [TLS] PSS and TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 20 Jan 2017 17:43:31 -0000

Draft 18 says:

   RSASSA-PSS algorithms  Indicates a signature algorithm using RSASSA-
      PSS [RFC3447] with MGF1.  The digest used in the mask generation
      function and the digest being signed are both the corresponding
      hash algorithm as defined in [SHS].  When used in signed TLS
      handshake messages, the length of the salt MUST be equal to the
      length of the digest output.  This codepoint is defined for use
      with TLS 1.2 as well as TLS 1.3.

What are the requirements for certificates when these RSSSA-PSS is used?

The text above indicates the salt length for TLS messages. There are no
restrictions placed on certificate signature salt lengths. Does this mean that
any valid salt length (from 0 to the maximum permitted) must be supported?

Additionally PSS signatures (see RFC4055) can be used with RSA keys
(rsaEncryption OID) and RSA-PSS only keys (id-RSASSA-PSS OID). Does the
RSASSA-PSS mean that both types must be accepted?

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shenson@drh-consultancy.co.uk, PGP key: via homepage.


From nobody Fri Jan 20 10:15:04 2017
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 484CD129694 for ; Fri, 20 Jan 2017 10:15:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.099
X-Spam-Level: 
X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199] 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 srADCBbupmgk for ; Fri, 20 Jan 2017 10:15:00 -0800 (PST)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 28A5B12943D for ; Fri, 20 Jan 2017 10:14:59 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 363081A682; Fri, 20 Jan 2017 20:14:58 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id uHAcYx7pvLfX; Fri, 20 Jan 2017 20:14:56 +0200 (EET)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 987F62310; Fri, 20 Jan 2017 20:14:56 +0200 (EET)
Date: Fri, 20 Jan 2017 20:14:55 +0200
From: Ilari Liusvaara 
To: Dr Stephen Henson 
Message-ID: <20170120181455.GA30791@LK-Perkele-V2.elisa-laajakaista.fi>
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Cc: "tls@ietf.org list" 
Subject: Re: [TLS] PSS and TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 20 Jan 2017 18:15:02 -0000

On Fri, Jan 20, 2017 at 05:43:21PM +0000, Dr Stephen Henson wrote:
> Draft 18 says:
> 
>    RSASSA-PSS algorithms  Indicates a signature algorithm using RSASSA-
>       PSS [RFC3447] with MGF1.  The digest used in the mask generation
>       function and the digest being signed are both the corresponding
>       hash algorithm as defined in [SHS].  When used in signed TLS
>       handshake messages, the length of the salt MUST be equal to the
>       length of the digest output.  This codepoint is defined for use
>       with TLS 1.2 as well as TLS 1.3.
> 
> What are the requirements for certificates when these RSSSA-PSS is used?

AFAIK, no special requirements.
 
> The text above indicates the salt length for TLS messages. There are no
> restrictions placed on certificate signature salt lengths. Does this mean that
> any valid salt length (from 0 to the maximum permitted) must be supported?

Well, the code I have written enforces the salt length restriction also on
any possible RSA-PSS certificates in chain.

This comes from not even having RSA-PSS validation code that could deal
with arbitrary salt length.
 
> Additionally PSS signatures (see RFC4055) can be used with RSA keys
> (rsaEncryption OID) and RSA-PSS only keys (id-RSASSA-PSS OID). Does the
> RSASSA-PSS mean that both types must be accepted?
 
I don't think you will see the latter outside some test sites for a
while...

But hmm, I think I should implement RSA-PSS only keys in some of my
stuff...


-Ilari


From brian@briansmith.org  Fri Jan 20 11:29:07 2017
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 340691294DC for ; Fri, 20 Jan 2017 11:29:07 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=briansmith-org.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 7lBgjqbwecgL for ; Fri, 20 Jan 2017 11:29:05 -0800 (PST)
Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 859AE1294D6 for ; Fri, 20 Jan 2017 11:29:05 -0800 (PST)
Received: by mail-io0-x22d.google.com with SMTP id j13so68907930iod.3 for ; Fri, 20 Jan 2017 11:29:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=C448mUmi5Sxr2kntvn5DdRNy2OgwRIxsGtg6wSPGyYs=; b=Rui7oh3uP9k0ZV9PnVHd7TYO7Reno7L2MZtcgBOYe05EVjjN8s82dxVIu8FfvDcXJD YINSORR5tANjiEap7y1W/2LzvBp4mD0ruF0ITTAyId6K9s/aOqeLjd6m/1gDUhAmMrDH AsK24z8FaySDOkhdYiKRyLbhQnc3vNsCKmPku4aRiyDjzJhcyiZIWpSUmhm/MgmRKCxf 0ZdgUi1esv6eDNJZfjew1OHlYI2/ZVXFt9J7EJySX6uYvX4q35gnzJhijZpZ0PQOFgUz w1TkZEedU8RJx1SJ7ITYZtmjW4KR2ekh9GSCbQ3cQaLz065sZF1wnGDRQtoaP/ewGHI/ saMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=C448mUmi5Sxr2kntvn5DdRNy2OgwRIxsGtg6wSPGyYs=; b=kXJnx8ubH++/QsAyVzUFCS/kvNAFOw2QK/kbUOLlUf3P2hFiLfggRYTcboknTUM5Mu SemZPducpl9cAmPZcFsmoMl6JkqxwLLrvqPCyOsXhRY2yzxHnkg/4OP0EksWK9lBOWhw VapOg94nkEM1ZgEz8gxYf9PeU0sk1t6emhe2BuVax15EtFFRWneDDtfDeUKgKnsIwRbL p4iNi0IfLPF/EF95bvrhWJRPZQ1tkiKkKRMJe2iOJgXxzbOEE65BHxj8Vd3wfzI+ug4k xhxVFntntWSz0ujfdNc1BA0lVrSjFl3dJtgI1i7hQgBXI8rnjbeR5GH5qUIWYMOImy+T q/ZQ==
X-Gm-Message-State: AIkVDXI8w4FK+Yelhy+jCuxID8YC5Dym8dV1FFvOXbLMY9E5ZN55UiXn0BBq9agFqo6L72FPrWCB8gxm1YbTug==
X-Received: by 10.107.162.194 with SMTP id l185mr16271359ioe.184.1484940544786;  Fri, 20 Jan 2017 11:29:04 -0800 (PST)
MIME-Version: 1.0
Received: by 10.36.65.206 with HTTP; Fri, 20 Jan 2017 11:29:04 -0800 (PST)
In-Reply-To: <20170120181455.GA30791@LK-Perkele-V2.elisa-laajakaista.fi>
References:  <20170120181455.GA30791@LK-Perkele-V2.elisa-laajakaista.fi>
From: Brian Smith 
Date: Fri, 20 Jan 2017 09:29:04 -1000
Message-ID: 
To: Ilari Liusvaara 
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org list" 
Subject: Re: [TLS] PSS and TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 20 Jan 2017 19:29:07 -0000

Ilari Liusvaara  wrote:
>> The text above indicates the salt length for TLS messages. There are no
>> restrictions placed on certificate signature salt lengths. Does this mean that
>> any valid salt length (from 0 to the maximum permitted) must be supported?
>
> Well, the code I have written enforces the salt length restriction also on
> any possible RSA-PSS certificates in chain.

RSA PSS with a zero-length salt is a deterministic,
subliminal-channel-free signature scheme. It is one of the few
signature schemes that structurally prevent an HSM from directly
leaking (parts of) the private key in an undetectable way. The PKCS#11
interface for RSA-PSS in particular only allows one to choose the
length of the salt, not the value of the salt, thus using a
zero-length salt is the only way to ensure that a HSM doesn't leak the
private key.

Accordingly, I think it's a bad idea for clients to enforce the salt
length requirement, and for the TLS 1.3 draft to specify a requirement
for a salt (that isn't empty). Although I originally suggested the
salt length requirement that was added to the TLS 1.3 draft, I now am
pretty sure it was a mistake. I'm pretty sure that PSS signatures can
be *proven* to be safe with just 1 bit of salt in TLS, because the
message that is being signed contains at least 1 random bit (from each
party). Note also that it has already been proven many years ago that
the salt length requirement that the TLS 1.3 draft currently imposes
is too large.

Similarly, in the case of the Web PKI, most CAs include at least one
random bit in each certificate they sign, so it should be possible to
construct the same proof for such certificates.

> This comes from not even having RSA-PSS validation code that could deal
> with arbitrary salt length.

This is currently the case in my own software (*ring* and webpki) too,
but I plan to make changes to both of them so that 0-length and maybe
1-bit salts are also acceptable, once the proof of security of shorter
salt lengths is done.

Note also that most deployed RSA-PSS certificates (that I've seen) are
generated from Microsoft's software, which was (is?) hard-coded to use
SHA-1 as the MGF digest function. Some newer software doesn't accept
SHA-1 as the MGF digest function and so there's a trap there,
regardless of the salt length issue.

>> Additionally PSS signatures (see RFC4055) can be used with RSA keys
>> (rsaEncryption OID) and RSA-PSS only keys (id-RSASSA-PSS OID). Does the
>> RSASSA-PSS mean that both types must be accepted?

It is better to implement id-RSASSA-PSS. (It is also good to enforce
that certificates with a keyUsage extension that doesn't indicate
encryption aren't used for RSA encryption, which is a related
problem.)

Cheers,
Brian
--
https://briansmith.org/


From nobody Fri Jan 20 12:37:15 2017
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 D15BC129452 for ; Fri, 20 Jan 2017 12:37:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 4mk-xi0m7rdQ for ; Fri, 20 Jan 2017 12:37:10 -0800 (PST)
Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (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 D47C2129454 for ; Fri, 20 Jan 2017 12:37:09 -0800 (PST)
Received: by mail-io0-x242.google.com with SMTP id c80so9200204iod.1 for ; Fri, 20 Jan 2017 12:37:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=EFAoVaR38Uftn0DJS0KzqVqvhR4Hp5bQrL09+83f6Vw=; b=mncZvqzLwh56JYrJuFtHXvnbqdaTCZx7KlgTguBlICgbBW9dSADCbYnGbFFujZkjOa cWNv5HZX4DSsxiI179Zjk256BpsvTsT7FAVHoWuC2Gz6Z9Bb7xHrWqXGWPa6XacQG514 jrq45bgtRI+q+Y3AdXNNcce94GmhFJ/REfKz9pLrFRfQQCDcxGWjwkqzwoQ11bWJCrBb N3wgoum4dyY4JvZMqDlBxvM636JhyOiIObnKxhAee7dnkXaVUX89g6lYygakniGA/8/P FLb+cHPMw5YNrGJjeT+COMwkPbsfcqrF3FHTTjcTPLvMKrCUbJLLcKSZ9RPC/VO9YUCg 7EHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=EFAoVaR38Uftn0DJS0KzqVqvhR4Hp5bQrL09+83f6Vw=; b=JrTZpp/+tIN8iLF+PL+fH3j4+0BVr+bc1BwBHYp/1HNk0hVX3ZF6Ili7dcgnhr6xzg CzEJIo2NOTu5Ozt30Nu/SR5IEqFxfAjMuQMjN194PLplXR5h9Z9DHyuN/DQnVhBPeZ6k uoFTYnSeZ7ocbNNkttmeoOWXWNzGu/osEvL8pUD5A3K6ceU+SRScke7mQjq3mgat95P1 k+B9AeJ8BlVdiwxNXc2ieZtzz+i3+KrSHut+zLrO8r6hSZt6krFSZNqfKGezsPFdsS9d z8ywEj8mw7vt2zMSf3xmk3EMQeTugsEZQsYXZb3LH7INefhe+PyCrOL29CW0Wwkitd1X XyDA==
X-Gm-Message-State: AIkVDXIkk/+/gf1lP4CQsTxh1+r+w20ULgKW0BsGxQnkWmLJKMvnKsp8Lzet7tHkrzFakz5YiDhbqjW7CuBE+g==
X-Received: by 10.107.134.36 with SMTP id i36mr14899947iod.168.1484944629197;  Fri, 20 Jan 2017 12:37:09 -0800 (PST)
MIME-Version: 1.0
Sender: alangley@gmail.com
Received: by 10.36.144.4 with HTTP; Fri, 20 Jan 2017 12:37:08 -0800 (PST)
In-Reply-To: 
References:  <20170120181455.GA30791@LK-Perkele-V2.elisa-laajakaista.fi> 
From: Adam Langley 
Date: Fri, 20 Jan 2017 12:37:08 -0800
X-Google-Sender-Auth: 66Ih6An38I2HnYlesp9DHgckthE
Message-ID: 
To: Brian Smith 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "tls@ietf.org list" 
Subject: Re: [TLS] PSS and TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 20 Jan 2017 20:37:13 -0000

On Fri, Jan 20, 2017 at 11:29 AM, Brian Smith  wrote:
> RSA PSS with a zero-length salt is a deterministic,
> subliminal-channel-free signature scheme. It is one of the few
> signature schemes that structurally prevent an HSM from directly
> leaking (parts of) the private key in an undetectable way.

Brian's disowned recommendation in the TLS 1.3 draft matches what I
suggest for PSS signatures:

* Salt length is the length of the hash function.
* MGF1 hash function is the same as the message hash function.
* The trailer field has the default value.

(I like Brian's idea, but I hate options, so I'm torn here.)

Certificates that don't match that format are at risk of not working
in Google products because we hate excessive options. (We'll see,
practically speaking, much we have to bend on that point, as always)


Cheers

AGL


From nobody Mon Jan 23 00:10:46 2017
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 BE39812949A for ; Mon, 23 Jan 2017 00:10:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.101
X-Spam-Level: 
X-Spam-Status: No, score=-10.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 jAC_FT-qdaI7 for ; Mon, 23 Jan 2017 00:10:44 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 767271295D5 for ; Mon, 23 Jan 2017 00:05:30 -0800 (PST)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E1363C04BD2C; Mon, 23 Jan 2017 08:05:30 +0000 (UTC)
Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.197]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v0N85SZt021095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 23 Jan 2017 03:05:30 -0500
Message-ID: <1485158728.3068.5.camel@redhat.com>
From: Nikos Mavrogiannopoulos 
To: Dr Stephen Henson , "tls@ietf.org list" 
Date: Mon, 23 Jan 2017 09:05:28 +0100
In-Reply-To: 
References: 
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Mon, 23 Jan 2017 08:05:31 +0000 (UTC)
Archived-At: 
Subject: Re: [TLS] PSS and TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 23 Jan 2017 08:10:45 -0000

On Fri, 2017-01-20 at 17:43 +0000, Dr Stephen Henson wrote:

> Additionally PSS signatures (see RFC4055) can be used with RSA keys
> (rsaEncryption OID) and RSA-PSS only keys (id-RSASSA-PSS OID). Does
> the RSASSA-PSS mean that both types must be accepted?

That's a quite interesting finding. Although that protocol behavior
seems to ease transition to RSASSA-PSS, it also paves the field for new
cross protocol attacks. A server which can sign with either of RSASSA-
PSS and RSA-PKCS1 and the same key is certainly less secure than a
server which can sign with either of them. The only way to enforce that
a key is restricted is by requiring the id-RSASSA-PSS OID for RSASSA-
PSS.

regards,
Nikos


From nobody Mon Jan 23 02:52:50 2017
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 582DE129B11 for ; Mon, 23 Jan 2017 02:52:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.099
X-Spam-Level: 
X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199] 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 AiVP65KhnRIm for ; Mon, 23 Jan 2017 02:52:46 -0800 (PST)
Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBF312956B for ; Mon, 23 Jan 2017 02:52:45 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 33EAA1EB89; Mon, 23 Jan 2017 12:52:44 +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-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id gFm-9UAFQQzX; Mon, 23 Jan 2017 12:52:44 +0200 (EET)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id E94ED21C; Mon, 23 Jan 2017 12:52:43 +0200 (EET)
Date: Mon, 23 Jan 2017 12:52:41 +0200
From: Ilari Liusvaara 
To: Nikos Mavrogiannopoulos 
Message-ID: <20170123105241.GB28101@LK-Perkele-V2.elisa-laajakaista.fi>
References:  <1485158728.3068.5.camel@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1485158728.3068.5.camel@redhat.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: 
Cc: "tls@ietf.org list" 
Subject: Re: [TLS] PSS and TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 23 Jan 2017 10:52:48 -0000

On Mon, Jan 23, 2017 at 09:05:28AM +0100, Nikos Mavrogiannopoulos wrote:
> On Fri, 2017-01-20 at 17:43 +0000, Dr Stephen Henson wrote:
> 
> > Additionally PSS signatures (see RFC4055) can be used with RSA keys
> > (rsaEncryption OID) and RSA-PSS only keys (id-RSASSA-PSS OID). Does
> > the RSASSA-PSS mean that both types must be accepted?
> 
> That's a quite interesting finding. Although that protocol behavior
> seems to ease transition to RSASSA-PSS, it also paves the field for new
> cross protocol attacks. A server which can sign with either of RSASSA-
> PSS and RSA-PKCS1 and the same key is certainly less secure than a
> server which can sign with either of them. The only way to enforce that
> a key is restricted is by requiring the id-RSASSA-PSS OID for RSASSA-
> PSS.

Unfortunately, dedicated RSA-PSS keys are pretty much undeployable, and
requirement to use those would be de facto the same as removing RSA
server signatures entierely from TLS 1.3[1].

I don't know any CA that would certify RSA-PSS keys. And adding new key
types is a slow process. Heck, Certifying ECDSA keys are poorly
supported among CAs[2].

And looking at RSA-PKCS1 and RSA-PSS, it doesn't seem likely that there
exists a EM that is both valid in RSA-PKCS1 and RSA-PSS for any
messages, unless keysizes are too small, hashes are too large or salts
are too large.

E.g. with 2048-bit keys, and SHA-512 with 512-bit salts, there are
126 octets to match, but only 64 octets to control, making it very
unlikely that suitable control value can be found. With longer keys,
each octet in key adds an octet to match but leaves octets to control
unchanged.


[1] Not that this wouldn't have security benefits, thanks to insecure
stuff SSL and earlier TLS versions pull off...

[2] Some commercial CAs (don't have list) and Let's Encrypt (signed 
with RSA[3] and even then most ACME software can't handle those)..

[3] TLS 1.2 and 1.3 allows mixing and matching RSA and ECDSA in
chain.


-Ilari


From nobody Wed Jan 25 04:49:34 2017
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 91E0A1298B5 for ; Wed, 25 Jan 2017 04:49:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.101
X-Spam-Level: 
X-Spam-Status: No, score=-10.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, 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 zd39nBZ2VjKf for ; Wed, 25 Jan 2017 04:49:31 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58A6B1295A9 for ; Wed, 25 Jan 2017 04:49:31 -0800 (PST)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 196D17F36F; Wed, 25 Jan 2017 12:49:32 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-115.brq.redhat.com [10.34.0.115]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v0PCnUgN004265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 25 Jan 2017 07:49:31 -0500
From: Hubert Kario 
To: tls@ietf.org
Date: Wed, 25 Jan 2017 13:49:25 +0100
Message-ID: <2661678.7zjSD2YDtc@pintsize.usersys.redhat.com>
User-Agent: KMail/5.3.3 (Linux/4.9.5-100.fc24.x86_64; KDE/5.29.0; x86_64; ; )
In-Reply-To: <92dcf6c4-60b9-c6d9-ed3d-fa9e8624d995@akamai.com>
References:  <92dcf6c4-60b9-c6d9-ed3d-fa9e8624d995@akamai.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart6298374.MmLHaSHSK8"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Wed, 25 Jan 2017 12:49:32 +0000 (UTC)
Archived-At: 
Subject: Re: [TLS] GREASE and TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 25 Jan 2017 12:49:32 -0000

--nextPart6298374.MmLHaSHSK8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

On Thursday, 19 January 2017 13:31:31 CET Benjamin Kaduk wrote:
> On 01/18/2017 04:49 PM, David Benjamin wrote:
> > Do people agree with this plan?
>=20
> Yes :)
>=20
> > I've left out psk_key_exchange_modes. It would be nice to GREASE that
> > too, but it uses u8 rather than u16 values. The natural generalization
> > is to reserve 0x?a instead of 0x?a?a. But then we lose 16 out of 256
> > code points, rather than 16 out of 65536 code points. Do people feel
> > this is an acceptable tradeoff? Perhaps a smaller pattern? Or is this
> > not worth bothering with?
>=20
> I feel like we're unlikely to come up with enough modes that we run out
> of space, so it is probably okay to grease it.  But I would be okay if
> people wanted to not do so, too.
>=20
> -Ben

+1 to greasing psk_key_exchange_modes

=2D-=20
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic
--nextPart6298374.MmLHaSHSK8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCgAGBQJYiJ7VAAoJEJKo0bgB0vX1cvIP/109qS1CUKfAIYZnxO9W+otI
EqzK3DN3DpgDFJvpblqz4DbAbdhF6/jOcx7ksImTy6zqNtUTgSpa0gMwk0PEP3kK
o/R6T82Ymtx3ZrPXN1akl/8N3pZe2UTn+7E6ort/BPnkeV9JzQxOlp/CYsr9JwCU
BWanChGxhlfX2cqwpCqOlLN1A5bQaZbfI6d4LWtKUGBrtQ8J8vjFdogi2agv5WqD
Mly93z2BWK+1Vfm3xt0ZsYLUXqTrOjAFTyTZXgpBdqDKLn5gQ/kgS31fAEL/VkLB
9UuWZgJbqXC4jCk5wFkPXTFQZovVRi+OQv+tQnPPGvdKn3dvUSL/wCVzhRAtIhzk
0ptvis9kAMKzuawdMvhjQFGJGQONXO1r2CxltbuxaelEv8hdHFPkHQdnv/aR6a0A
BmiXidCpWkFXf4Pdscq5oK3n4/TjXPG9/zvOawEToTQG2v0WAFJrnV+dRaCaCxzS
Sr5Gv6/QM4yHpjgXhF5qLjSKPJeTc86HTzuF+82K4DdguPw3riGa5Vw9kvH/P+Ab
kmLCCbM/F359cnu9XQX4Se9X6jJTUlNdWnWos7PUUl4WruglmvjAU0zfFFMmX1L7
oS9poaCAC9ZuHLAbnViFPZ6dXEY+i+//nCz4Dv7rsr2kGBhpev1xh0qMLEJzXedy
GDe1yVedmcDm35KhtcaP
=jbsc
-----END PGP SIGNATURE-----

--nextPart6298374.MmLHaSHSK8--


From nobody Thu Jan 26 08:10:09 2017
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 17D95129859 for ; Thu, 26 Jan 2017 08:10:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.055
X-Spam-Level: 
X-Spam-Status: No, score=-3.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 YRVfUiDEs9H5 for ; Thu, 26 Jan 2017 08:10:02 -0800 (PST)
Received: from nm26-vm6.bullet.mail.ne1.yahoo.com (nm26-vm6.bullet.mail.ne1.yahoo.com [98.138.91.119]) (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 41061129850 for ; Thu, 26 Jan 2017 08:10:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1485447001; bh=17jVg9XsfCBORsw45IxAgGM2Ht7bwFzbLjJAEuYJynU=; h=Date:From:Reply-To:To:Cc:Subject:References:From:Subject; b=adrdnVF8nDrXLoH2O3Js/682e+G0bYYJ/e71uglZtpjCpRRBGhIHIu/9kcnt/UL4SeoEdDCLqqc2+94xKLELKw5fuDPEZlKJ0CuRu+ANX5SJX7BE4tO8y17hglViph/bSsz5wZQAMNnp5p0HhhdW57ofMKRrEqREWrp7OLWhJ+lm3m2H7PsjXWIqaL6KcBnT+JcanME5Gl2yzn7koOANZYc1hjUnW4+l9ZyWon2hteR9sU2Hg2KsAyo8PGVbOM3o8e7+3B/O3/DlMowIROLB7vXT4FmVSRwJIL9icJO3vlEktcjCDyk3ojewvdhyqUkYu3fIiG8De/AkYv3BsEFehg==
Received: from [98.138.101.128] by nm26.bullet.mail.ne1.yahoo.com with NNFMP;  26 Jan 2017 16:10:01 -0000
Received: from [98.138.226.167] by tm16.bullet.mail.ne1.yahoo.com with NNFMP;  26 Jan 2017 16:10:01 -0000
Received: from [127.0.0.1] by omp1068.mail.ne1.yahoo.com with NNFMP; 26 Jan 2017 16:10:01 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 390075.63698.bm@omp1068.mail.ne1.yahoo.com
X-YMail-OSG: mDg9WfgVM1lpva3Gt_z495SMjtGX5dp1PLtRbL1h620WcCyhiEkmcGn.gE4PBFd t2hdksy3kWgDn04yEKSAD9PkcNLKDsy3dPOWJOJlon7fNsAbpeTKQQSk8xXkN6JCYwZkHJOxeFfo Bf3bjJ.OczDt.ecQPY3D8WsWAMgTODk7wbHMvvVlsdDVCQ5zQczUPAZc1JrrKBOM1g.t3yd1Cc23 RLyLXGXsLg83V6sOnLzj3No0_h0fUKTH6y9GEQ.y_iO2tj7EVgMJlwPRzTGqr5ZJ1_obG2mJ5Fj0 Bvf23tYsn9OMdLsh.5sb4FM6A.GxeJyP0sOOw8Ifd2pNHVAEzPPX3s9XxaaNCBoXHCoPYB2ubhyi QFnPgU2nU7j.ku7KzcblqS__LvIqKYk2qz1nYM5S4.KT2wwNk_D8Cr6BWMZaK6DiT2XcyWa0bS6W MgCDKdW_UEDB0W90JjD.8HdgCbb4UEWg1lcwXmjjcOzi5VN73ato4wMQ9WogbidSDoRiN8INBd3B AWxXZDuxSkCABDTfg79SAlUpx6MHHeeQOtSA-
Received: from jws200066.mail.ne1.yahoo.com by sendmailws115.mail.ne1.yahoo.com; Thu, 26 Jan 2017 16:10:00 +0000; 1485447000.622
Date: Thu, 26 Jan 2017 16:10:00 +0000 (UTC)
From: 
To: IETF TLS 
Message-ID: <513927626.1360652.1485447000217@mail.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
References: <513927626.1360652.1485447000217.ref@mail.yahoo.com>
Archived-At: 
Cc: alexis.lagoutte@gmail.com
Subject: [TLS] Wireshark Download for TLS1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: nalini.elkins@insidethestack.com
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, 26 Jan 2017 16:10:08 -0000

All,

If you want to download a WorkInProgress version of Wireshark that supports TLS1.3 (latest version of draft -18 only!).   Please go to:

https://www.wireshark.org/download/automated/

THIS IS NOT THE PRODUCTION VERSION OF WIRESHARK!!!

We owe HUGE thanks to Peter Wu & Alexis La Goutte (core Wireshark developers) for the TLS1.3 dissector.  I did some minor, initial work on the dissector but it is really their great effort and continued support that is making this dissector available for us.   Thank you guys so much!!!

BTW, we had started an email list to discuss diagnostic & implementation experiences for TLS.

https://www.ietf.org/mailman/listinfo/tls-implementers

Shall we move to that list to discuss?   Maybe we can share PCAPs.

Thanks,

Nalini Elkins
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360


From nobody Thu Jan 26 08:31:57 2017
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 AB08912989E for ; Thu, 26 Jan 2017 08:31:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.499
X-Spam-Level: 
X-Spam-Status: No, score=-7.499 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, RP_MATCHES_RCVD=-3.199, 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=lekensteyn.nl
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 j9B_y1ddWAFd for ; Thu, 26 Jan 2017 08:31:54 -0800 (PST)
Received: from mail.lekensteyn.nl (mail.lekensteyn.nl [IPv6:2a02:2308::360:1:25]) (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 593E91298A4 for ; Thu, 26 Jan 2017 08:31:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lekensteyn.nl; s=s2048-2015-q1;  h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=hdAg81vPoCq5R1I2n34jcFGvgDum4+LzpIE7Pdq+ms0=;  b=d5/IkNyE1PgkWVD0pq3az7fwmE5OI9wbsFO5+unDhPhaLZRriuZd6v2Nq2mnc8upzgT7PL+LvL8sAplt63yKGNJWMoXahQp5E6BLyNYOf4VOe8KC3PIq+/ylJH3P/zYPLk8gZ/2Wr/0gHGBCcd4wwAUH717ZvWYbLpQdEJbH0DrgnEGX+U0OXJacQYvslz0Idb4EbXIz0h2VnfYOcAouxsEI4/s1iqc7Vr2U5tpbmqBe6Mw5wMfovEBBLp5fz1p93Z/PHs2G/KIP6NVrXISssBXmBGLjV7EYbmPlhg70h+E7bEv8LLC7hg9zSiemV8ii2C0K3CT4H/qvMiENcZ24NQ==;
Received: by lekensteyn.nl with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cWmxi-0004YJ-8r; Thu, 26 Jan 2017 17:31:51 +0100
Date: Thu, 26 Jan 2017 17:31:48 +0100
From: Peter Wu 
To: nalini.elkins@insidethestack.com
Message-ID: <20170126163148.GD20541@al>
References: <513927626.1360652.1485447000217.ref@mail.yahoo.com> <513927626.1360652.1485447000217@mail.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <513927626.1360652.1485447000217@mail.yahoo.com>
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: 
Cc: IETF TLS , alexis.lagoutte@gmail.com
Subject: Re: [TLS] Wireshark Download for TLS1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 26 Jan 2017 16:31:56 -0000

Hi all,

This is indeed work in progress, the current state can be tracked at:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12779

Note for TLS implementers: Wireshark supports decryption when provided
with the master secret (TLS 1.2 and before), but with TLS 1.3 there are
more secrets. The current plan is to accept the client/server
handshake/application traffic secrets (as opposed to the more sensitive
Handshake/Master secrets) following the format proposed by BoringSSL:
https://code.wireshark.org/review/19801

If everything goes well, Wireshark 2.4 should be the first stable
version with TLS 1.3 support.

Kind regards,
Peter

On Thu, Jan 26, 2017 at 04:10:00PM +0000, nalini.elkins@insidethestack.com wrote:
> All,
> 
> If you want to download a WorkInProgress version of Wireshark that supports TLS1.3 (latest version of draft -18 only!).   Please go to:
> 
> https://www.wireshark.org/download/automated/
> 
> THIS IS NOT THE PRODUCTION VERSION OF WIRESHARK!!!
> 
> We owe HUGE thanks to Peter Wu & Alexis La Goutte (core Wireshark developers) for the TLS1.3 dissector.  I did some minor, initial work on the dissector but it is really their great effort and continued support that is making this dissector available for us.   Thank you guys so much!!!
> 
> BTW, we had started an email list to discuss diagnostic & implementation experiences for TLS.
> 
> https://www.ietf.org/mailman/listinfo/tls-implementers
> 
> Shall we move to that list to discuss?   Maybe we can share PCAPs.
> 
> Thanks,
> 
> Nalini Elkins
> Inside Products, Inc.
> www.insidethestack.com
> (831) 659-8360


From nobody Thu Jan 26 08:41:48 2017
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 D68D612988D for ; Thu, 26 Jan 2017 08:41:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, 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 qRk1vqbtyFwB for ; Thu, 26 Jan 2017 08:41:44 -0800 (PST)
Received: from mx496502.smtp-engine.com (mx496502.smtp-engine.com [IPv6:2001:8d8:968:7d00::19:7e53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7D0B129881 for ; Thu, 26 Jan 2017 08:41:43 -0800 (PST)
Received: from mail-yb0-f171.google.com (mail-yb0-f171.google.com [209.85.213.171]) by mx496502.smtp-engine.com (Postfix) with ESMTPSA id 2B2D910D0 for ; Thu, 26 Jan 2017 16:41:37 +0000 (GMT)
Received: by mail-yb0-f171.google.com with SMTP id w194so151373242ybe.0 for ; Thu, 26 Jan 2017 08:41:37 -0800 (PST)
X-Gm-Message-State: AIkVDXKKIayl6OmfwGAEGo3N0IuLLPNVYItcPxjn+by29TruoP9P2omauMGSam9vUr5n7DMplg7BlYb9pyk+Ig==
X-Received: by 10.129.70.8 with SMTP id t8mr2542547ywa.61.1485448895353; Thu, 26 Jan 2017 08:41:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.170.211 with HTTP; Thu, 26 Jan 2017 08:41:35 -0800 (PST)
In-Reply-To: <20170126163148.GD20541@al>
References: <513927626.1360652.1485447000217.ref@mail.yahoo.com> <513927626.1360652.1485447000217@mail.yahoo.com> <20170126163148.GD20541@al>
From: Matt Caswell 
Date: Thu, 26 Jan 2017 16:41:35 +0000
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Peter Wu 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: alexis.lagoutte@gmail.com, IETF TLS 
Subject: Re: [TLS] Wireshark Download for TLS1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 26 Jan 2017 16:41:47 -0000

On 26 January 2017 at 16:31, Peter Wu  wrote:
> Hi all,
>
> This is indeed work in progress, the current state can be tracked at:
> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3D12779
>
> Note for TLS implementers: Wireshark supports decryption when provided
> with the master secret (TLS 1.2 and before), but with TLS 1.3 there are
> more secrets. The current plan is to accept the client/server
> handshake/application traffic secrets (as opposed to the more sensitive
> Handshake/Master secrets) following the format proposed by BoringSSL:
> https://code.wireshark.org/review/19801

FYI, OpenSSL is also planning to adopt that format:

https://github.com/openssl/openssl/pull/2287

Matt



>
> If everything goes well, Wireshark 2.4 should be the first stable
> version with TLS 1.3 support.
>
> Kind regards,
> Peter
>
> On Thu, Jan 26, 2017 at 04:10:00PM +0000, nalini.elkins@insidethestack.co=
m wrote:
>> All,
>>
>> If you want to download a WorkInProgress version of Wireshark that suppo=
rts TLS1.3 (latest version of draft -18 only!).   Please go to:
>>
>> https://www.wireshark.org/download/automated/
>>
>> THIS IS NOT THE PRODUCTION VERSION OF WIRESHARK!!!
>>
>> We owe HUGE thanks to Peter Wu & Alexis La Goutte (core Wireshark develo=
pers) for the TLS1.3 dissector.  I did some minor, initial work on the diss=
ector but it is really their great effort and continued support that is mak=
ing this dissector available for us.   Thank you guys so much!!!
>>
>> BTW, we had started an email list to discuss diagnostic & implementation=
 experiences for TLS.
>>
>> https://www.ietf.org/mailman/listinfo/tls-implementers
>>
>> Shall we move to that list to discuss?   Maybe we can share PCAPs.
>>
>> Thanks,
>>
>> Nalini Elkins
>> Inside Products, Inc.
>> www.insidethestack.com
>> (831) 659-8360
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From nobody Thu Jan 26 11:23:55 2017
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 11CD21299AD for ; Thu, 26 Jan 2017 11:23:55 -0800 (PST)
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 (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 PPXsrWsX0rsO for ; Thu, 26 Jan 2017 11:23:53 -0800 (PST)
Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 633B31299A4 for ; Thu, 26 Jan 2017 11:23:53 -0800 (PST)
Received: by mail-qt0-x235.google.com with SMTP id w20so31312817qtb.1 for ; Thu, 26 Jan 2017 11:23:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=jVrfdXGknkUdZ49ebc7RzSDETGDjXXNGz+gl4lodVrc=; b=Z5wrldNvgLq5HDXtft6G49n35V/nJQmTZmQEOnzbYoDNZ2LxDasu/4HpDYTo3XGA02 AeqN5ia5SIN8uY/rXAuXIjP5yJfXG6JnJkc/iKFYYxF0NTRDSIRwrzILfvKU6hpsBU83 jygwQqnXszWZ/494kOBUBtXMF4jj5CLBMNNl8=
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:subject :message-id:date:to:mime-version; bh=jVrfdXGknkUdZ49ebc7RzSDETGDjXXNGz+gl4lodVrc=; b=ANBvrxg8HBlOiZMPkL2CLaUwBglYN1u8w3uUblpn3s9Y1trv44JMkRA/hljZpxuEyK RWmX4aji1KVUftijr/2YaoLnnIXA6NpmaZd4MGWczNJ/6Ex7bbFCbr/BlFV+M5WewiPE ekiSF1V5yGVtlCmwRZVAEPTxtIWe0s9SF9SainqVLjl0isFJSJY9b7NBkbwOlSpBLzGw VcxL/k7XTeXhw6C9kR6xvFKp/jeUtc0RBtm6O4eaY6wTYU7QbKKhDAaIMz4Ij4pMEIKz Ot6cro7KeDWngUhK5z2i/9pjCJwQiFqi+eT59x4J8Eyvtk08VWZmXJVP/G4TgsapXvlH LD2Q==
X-Gm-Message-State: AIkVDXLesHGUyID5xs0GktylFEJUsfZoxdujNz3aNonUCEXFXN65n34Kgvec/7lr/nHmhA==
X-Received: by 10.200.54.182 with SMTP id a51mr4370504qtc.221.1485458630487; Thu, 26 Jan 2017 11:23:50 -0800 (PST)
Received: from [172.16.0.92] (pool-173-73-120-80.washdc.east.verizon.net. [173.73.120.80]) by smtp.gmail.com with ESMTPSA id s75sm1978554qka.36.2017.01.26.11.23.49 for  (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 26 Jan 2017 11:23:49 -0800 (PST)
From: Sean Turner 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: 
Date: Thu, 26 Jan 2017 14:23:48 -0500
To: "" 
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: [TLS] Issues and PRs for draft-ietf-tls-iana-registry-updates
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 26 Jan 2017 19:23:55 -0000

I submitted a PR to address some editorial issues:
https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/5

I also created an issue/PR that adds a =E2=80=9Crecommended" column for =
exporters; its another registry that could use it.  I followed the same =
model as the CS registry, namely put a YES in ones defined in standards =
track RFCs and specify that future exporters need to say how to populate =
column as well as requiring that standards RFCs only get a YES.  The PR =
can be found here:
https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/9

We needed some designated expert instructions for exporters.  Again, I =
adopted the =E2=80=9Cverify publicly available spec=E2=80=9D approach =
used elsewhere.  The PR can be found here:
https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/10

We don=E2=80=99t have instructions for future CS registry values being =
marked as YES.  The question is should we require that all Yeses be from =
standards track RFCs:
https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/issues/8
If do go with this approach, then we=E2=80=99ll need to add a pointer =
from the registry to this draft:
https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/issues/11

Comments welcome.

spt=


From nobody Thu Jan 26 12:15:16 2017
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 B2793129AA7 for ; Thu, 26 Jan 2017 12:15:14 -0800 (PST)
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 (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 YzH3jGtFAcq0 for ; Thu, 26 Jan 2017 12:15:13 -0800 (PST)
Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 76973129AA6 for ; Thu, 26 Jan 2017 12:15:13 -0800 (PST)
Received: by mail-qt0-x22b.google.com with SMTP id x49so94327267qtc.2 for ; Thu, 26 Jan 2017 12:15:13 -0800 (PST)
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=nNJSIrdc1JO51p1z2rJPfbAF0QaBi0QvPFmaOwEgIcs=; b=dQVaVAgXk345d+9TJGFr5re6jB8p8fFVv9K8YXFJ8sUMe2xZvlgU9uFTv9F3j0PnOn 9wvRcZs7Db+r1Pg5UtER4p1NxxRtlYubUX0tBGi1WzDa8g9adPBRixsvo6AkzRUheFqe TWGqwW2PY7k2jrL8iFghgkW6DITIeBouP8I6Q=
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=nNJSIrdc1JO51p1z2rJPfbAF0QaBi0QvPFmaOwEgIcs=; b=GOHIZG0XBS2SHGwXFhGqYOK90Zscydzvhd7G+eaumSPC2SRhe8qU7g/K6c/ShwUaiL S7kSbrzknsQNT+wwmBODIUUyYqYpKWXeleGKnd6+bPshttyHsNJgAN+UYH3hBqmarHxS xhGqs+yXbf2js+3GgsktFl1nJZhoF/oYkxHzw3dBZLMFzjlP+W5ikxlGePYnc0+3CX5W kFbTTrwxeylPzcSJDViMzvflqcFjXSr/krJJrgj7hYwiq2Adp/fYkex9RzOUJb/vvUL/ 5k3tW8nl3zzSxlSMArM1UrhbEP8hqHKWYpk3texww4PgY1X+sXxXy+vbGDavpYniSlLN o+Gg==
X-Gm-Message-State: AIkVDXJDtzWaVaEcn/zAlJk8wn85qij3Y3x7f+z05gGsAj4QtWNT9xSFAArGPXYW5gbJ9Q==
X-Received: by 10.237.53.236 with SMTP id d41mr4814509qte.135.1485461712585; Thu, 26 Jan 2017 12:15:12 -0800 (PST)
Received: from [172.16.0.92] (pool-173-73-120-80.washdc.east.verizon.net. [173.73.120.80]) by smtp.gmail.com with ESMTPSA id 140sm2099934qkj.19.2017.01.26.12.15.11 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 26 Jan 2017 12:15:11 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Sean Turner 
In-Reply-To: 
Date: Thu, 26 Jan 2017 15:15:09 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <1930665D-B53F-4333-B887-A6D895BE732A@sn3rd.com>
References: 
To: David Benjamin 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] GREASE and TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 26 Jan 2017 20:15:15 -0000

> On Jan 18, 2017, at 17:49, David Benjamin  wrote:
> 
> Do people agree with this plan?

Looks like we got general agreement this is a good approach to follow.

spt


From nobody Fri Jan 27 05:30:11 2017
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 A9377129574 for ; Fri, 27 Jan 2017 05:30:10 -0800 (PST)
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 wN5WZOv9ukSr for ; Fri, 27 Jan 2017 05:30:08 -0800 (PST)
Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3820129571 for ; Fri, 27 Jan 2017 05:30:08 -0800 (PST)
Received: from pc1 ([2001:2012:127:3e00:b3bf:56a1:a140:6086]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 256bits, ECDHE-RSA-AES256-GCM-SHA384) by zucker.schokokeks.org with ESMTPSA; Fri, 27 Jan 2017 14:30:05 +0100 id 00000000000000FC.00000000588B4B5E.00006568
Date: Fri, 27 Jan 2017 14:30:03 +0100
From: Hanno =?UTF-8?B?QsO2Y2s=?= 
To: tls@ietf.org
Message-ID: <20170127143003.36c20329@pc1>
X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: [TLS] TLS 1.3 / RSA-PSS and unusual key sizes
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 27 Jan 2017 13:30:10 -0000

Hi,

I wanted to warn people about a potential source of bugs with the
deployment of RSA-PSS in TLS 1.3.

Usually the RSA key modulus is a multiple of 8 (2048, 4096 etc.).
However there's no rule that RSA keys can't have other sizes.

Implementing PSS with support for arbitrary key sizes is a bit more
complicated than implementing it for multiples of 8. I wrote the PSS
implementation of NSS as a summer of code project a couple of years ago
and I remember that my first implementation completely failed to
consider this. (The fix for that never got merged afair, I informed NSS
developers about this.)

Back then I also reported a bug in OpenSSL:
https://rt.openssl.org/Ticket/Display.html?id=3D2315&user=3Dguest&pass=3Dgu=
est

Long story short: It's not unlikely that there are more PSS
implementations having problems with this.
So I strongly recommend that all implementors of TLS 1.3 test their
implementations for key sizes from n*8+1 to N*8+7.

Such keys are rare, but they do exist in the wild. If implementations
failing on that get shipped widely we may see random unexplained errors
when people start migrating to TLS 1.3 in masses.

I had actually considered proposing to change TLS 1.3 in a way that
such keys would be simply forbidden. But I did a check on the censys
data and there were too many of them in the wild, so I thought it
wasn't a feasible idea.

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

mail/jabber: hanno@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42


From nobody Mon Jan 30 13:41:18 2017
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 A04AB1295F8 for ; Mon, 30 Jan 2017 13:41:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.72
X-Spam-Level: 
X-Spam-Status: No, score=-17.72 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 RBauzaZLfHhs for ; Mon, 30 Jan 2017 13:41:14 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81856129411 for ; Mon, 30 Jan 2017 13:41:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8200; q=dns/txt; s=iport; t=1485812474; x=1487022074; h=from:to:subject:date:message-id:mime-version; bh=ghmfTEk0kUBo1SNDVlIob7aIjAgXuD+SgPWpLmS7UCc=; b=PfyUhhGidFbEyZLuQahjk/KM0CNCJfiHoko4M2N9/nxWxYg+cayRtSD1 H7bdHZaEZ018Ua0kWLr6g57FcVDH651WEkboWYTzJ4nA0eWtXZNDjdDeE 1e5iuvzHfiunR0WXA0FWZmGXWfSR2S/l/tpvpZ6zTpifyqgDQ98XDL/89 A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ARAQCJso9Y/5hdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnBkYYEQjVeVH4xshSuCDIUSgzg/GAECAQEBAQEBAWIohR1eAYE?= =?us-ascii?q?AJgEEG4lZm0CSJosYAQEBAQYBAQEBASOGS4cEgh6FewWVQIYUAYFMkCWRAJJ+A?= =?us-ascii?q?R84gUsVhnSGaweBKYEMAQEB?=
X-IronPort-AV: E=Sophos;i="5.33,312,1477958400";  d="scan'208,217";a="378353050"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jan 2017 21:41:13 +0000
Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v0ULfCxR009006 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 30 Jan 2017 21:41:13 GMT
Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 30 Jan 2017 16:41:12 -0500
Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1210.000; Mon, 30 Jan 2017 16:41:11 -0500
From: "Scott Fluhrer (sfluhrer)" 
To: "" 
Thread-Topic: Question about unrecognized extension types in the TLS 1.3 client hello message
Thread-Index: AdJ7QZAvwr3Tl75aTkKB/t+x3+5diw==
Date: Mon, 30 Jan 2017 21:41:11 +0000
Message-ID: <747fda8b962b4edfab70afe2af58df36@XCH-RTP-006.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.98.2.62]
Content-Type: multipart/alternative; boundary="_000_747fda8b962b4edfab70afe2af58df36XCHRTP006ciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: [TLS] Question about unrecognized extension types in the TLS 1.3 client hello message
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 30 Jan 2017 21:41:17 -0000

--_000_747fda8b962b4edfab70afe2af58df36XCHRTP006ciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

My question: in TLS 1.3, if the client inserts an extension of a type that =
the server does not recognize, how must the server behave?  Is it required =
that the server just ignore the extension, or can it take some other action=
 (e.g. ignore the client hello)?

Background (why I'm asking): one of the things we've been doing is seeing h=
ow we might retrofit postquantum security into TLS 1.3; I know that the WG =
does not want to address this now, however I believe it will eventually; id=
eally, we could later create an RFC on how to do this within TLS 1.3 ( with=
out having to come up with TLS 1.4).

The specific subtask we're looking at is how a postquantum key exchange (an=
d a nonpostquantum one) can be used to generate keys.  Yes, I know that's b=
een proposed before; I just want to make sure that it's actually kosher by =
the rules of TLS 1.3.  One goal that we have is to be able to have backward=
s compatibility with TLS 1.3 implementations that don't know about these po=
st-quantum extensions.  One of the things we're looking at is having the cl=
ient include an extension that would have some of the data; we would set th=
ings up so that if the server ignores the extension, the protocol acts "cor=
rectly" (that is, if the client and the server are both willing to use the =
same group, they'll interoperate, if not, then the connection will fail bec=
ause both sides don't share a group in common).

So, a key requirement of this specific type extension is that the server ig=
nores an extension it doesn't recognize.  We could do it without adding an =
extension; however that gets rather uglier.

I've been going through the TLS 1.3 draft (draft-ietf-tls-tls13-18), and th=
ere doesn't appear to be any MUST statements that says that the server igno=
res extensions it doesn't recognize.  There's a statement that a client MUS=
T abort if it gets an extension it doesn't expect, but there's no similar l=
anguage for the server.  Presumably, the server is supposed to be silent ab=
out zero length extensions from the client (as the draft states that the cl=
ient sends a zero length extension for any type that it doesn't need to sen=
d, but is willing to receive in reply), however the extensions I'm asking a=
bout will not have zero length.

Is it the intension of the WG that the client is able to insert extensions =
into the client hello that the server might not expect?  If it is, could th=
e next version of the draft insert a MUST statement to that effect?

Thank you.

--_000_747fda8b962b4edfab70afe2af58df36XCHRTP006ciscocom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











My question: in TLS 1.3, if the client inserts an ex=
tension of a type that the server does not recognize, how must the server b=
ehave?  Is it required that the server just ignore the extension, or c=
an it take some other action (e.g. ignore
 the client hello)?


 


Background (why I’m asking): one of the things=
 we’ve been doing is seeing how we might retrofit postquantum securit=
y into TLS 1.3; I know that the WG does not want to address this now, howev=
er I believe it will eventually; ideally, we could
 later create an RFC on how to do this within TLS 1.3 ( without having to c=
ome up with TLS 1.4).


 


The specific subtask we’re looking at is how a=
 postquantum key exchange (and a nonpostquantum one) can be used to generat=
e keys.  Yes, I know that’s been proposed before; I just want to=
 make sure that it’s actually kosher by the rules of
 TLS 1.3.  One goal that we have is to be able to have backwards compa=
tibility with TLS 1.3 implementations that don’t know about these pos=
t-quantum extensions.  One of the things we’re looking at is hav=
ing the client include an extension that would have some
 of the data; we would set things up so that if the server ignores the exte=
nsion, the protocol acts “correctly” (that is, if the client an=
d the server are both willing to use the same group, they’ll interope=
rate, if not, then the connection will fail because
 both sides don’t share a group in common).


 


So, a key requirement of this specific type extensio=
n is that the server ignores an extension it doesn’t recognize. =
 We could do it without adding an extension; however that gets rather uglie=
r.


 


I’ve been going through the TLS 1.3 draft (dra=
ft-ietf-tls-tls13-18), and there doesn’t appear to be any MUST statem=
ents that says that the server ignores extensions it doesn’t recogniz=
e.  There’s a statement that a client MUST abort if
 it gets an extension it doesn’t expect, but there’s no similar=
 language for the server.  Presumably, the server is supposed to be si=
lent about zero length extensions from the client (as the draft states that=
 the client sends a zero length extension for any
 type that it doesn’t need to send, but is willing to receive in repl=
y), however the extensions I’m asking about will not have zero length=
.


 


Is it the intension of the WG that the client is abl=
e to insert extensions into the client hello that the server might not expe=
ct?  If it is, could the next version of the draft insert a MUST state=
ment to that effect?


 


Thank you.






--_000_747fda8b962b4edfab70afe2af58df36XCHRTP006ciscocom_--


From nobody Mon Jan 30 13:45:48 2017
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 4D2A5129621 for ; Mon, 30 Jan 2017 13:45:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level: 
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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=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 vNNPtoc2DZLr for ; Mon, 30 Jan 2017 13:45:44 -0800 (PST)
Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 EDD741295BA for ; Mon, 30 Jan 2017 13:45:43 -0800 (PST)
Received: by mail-it0-x22e.google.com with SMTP id 203so204024920ith.0 for ; Mon, 30 Jan 2017 13:45:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=tN35otHS9/OjF5SnXbsD93LE9iSsw0uihM3b2iMVsPU=; b=YAaHla9D5VsrWGR9DF8DuGoMobYRM5Uplnizy4ol+LdhGY6MOs4Ma1QEwZj3n1DoyU vM8SPcSYVYQntJZUzkTaoirYsdUmIHl3vA9jIdGOUpjAXa6UDDeyZfKMDDLOP0KCXgSN 7mY6WOne4maf3kR3XEvac/faDm+6Z4dYgDT+M2iNVaZfytwrg5VnJR2NzGRc3p3duzwo /B/w1+UaUSVOT7LcopACyx6k1kfMdx/e0L2FBokrCgzY7oTPZgrrNXCk6a2G4dLnNJNH yM7SI6incILGqtBy4Bg72QJBH1YLVhMmWyfxISTiGZcjqSpBgpRszu0EsNu1BXlC8mTS CXgg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=tN35otHS9/OjF5SnXbsD93LE9iSsw0uihM3b2iMVsPU=; b=jgljKdYtCybtSPTBFNEEeosF3U8IMi1PMOPuTGXsBAC/3nuLZTccF+0tT3N9TpYLAx NKqomxCjXJH8FhgjlxfTIftb3a7kmb4iWpJKbQWX0HrArkaLM/YgoXLciLyT/1DJpWWT JPzPpHruzqR/vGPzZDbVKPHuwam3+FXScpRo3FlbBgPZot7fJQZ/mVtVr8iVyMrE3HBF vr5zYtovz1j1gAQsK/LZiTqI0Ts5w0V4T+l3KFWcR2W3IPlZdhBBp+fn/XssKf3iLuqh zAotU7b/vB1lhKqnHtZRbwk3/nUiFlXFlB/LFiVSUglQJchmOaUM7ncRSVVN0+852+Nl Qshg==
X-Gm-Message-State: AIkVDXIavuyqW7crwaot97hFbXrM9S7e8MTfk8HPqNovvEKNmL7asHf18JM2+BZHSGZtmGrsVjXSr9XQ6FRBzg==
X-Received: by 10.36.41.7 with SMTP id p7mr4870975itp.92.1485812743298; Mon, 30 Jan 2017 13:45:43 -0800 (PST)
MIME-Version: 1.0
Sender: alangley@gmail.com
Received: by 10.36.153.135 with HTTP; Mon, 30 Jan 2017 13:45:26 -0800 (PST)
In-Reply-To: <747fda8b962b4edfab70afe2af58df36@XCH-RTP-006.cisco.com>
References: <747fda8b962b4edfab70afe2af58df36@XCH-RTP-006.cisco.com>
From: Adam Langley 
Date: Mon, 30 Jan 2017 13:45:26 -0800
X-Google-Sender-Auth: BybV-ETE0neHlvOpRkdyAmLssMI
Message-ID: 
To: "Scott Fluhrer (sfluhrer)" 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "" 
Subject: Re: [TLS] Question about unrecognized extension types in the TLS 1.3 client hello message
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 30 Jan 2017 21:45:46 -0000

On Mon, Jan 30, 2017 at 1:41 PM, Scott Fluhrer (sfluhrer)
 wrote:
> My question: in TLS 1.3, if the client inserts an extension of a type that
> the server does not recognize, how must the server behave?  Is it required
> that the server just ignore the extension, or can it take some other action
> (e.g. ignore the client hello)?

The server must ignore unknown extensions.


Cheers

AGL


From nobody Mon Jan 30 13:56:06 2017
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 DC31C129630 for ; Mon, 30 Jan 2017 13:56:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.897
X-Spam-Level: 
X-Spam-Status: No, score=-5.897 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.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, 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=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 A0e-F8a8jZAV for ; Mon, 30 Jan 2017 13:56:03 -0800 (PST)
Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 E469512962A for ; Mon, 30 Jan 2017 13:56:02 -0800 (PST)
Received: by mail-qt0-x22a.google.com with SMTP id k15so218059462qtg.3 for ; Mon, 30 Jan 2017 13:56:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fF7RoKVHRqqdaEAieuq7prxIFHAWKMPYa01EF/loRzU=; b=RUZYx9DiJYPsbH1nDXLNztOIztfnGWl1c+ThQtmo4tVOlz06AO8ceBVyonA7Pm7nW5 0voQc2Ct5LGaIlINApS+AcGXK9gDeqHOo4DEd7k2Q3IlRzPgSfOEdJi+pWdUjbPJxXnW RofELQpZIpVmtlTjP4HRTGiKYyJnsi7Edgsds=
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=fF7RoKVHRqqdaEAieuq7prxIFHAWKMPYa01EF/loRzU=; b=oL5X+ERxJSe87ylSRnP7YsDec0Xg1vsiK6X7UHWlNDw9Ax85O+fe4WjNttghk4Nz8A PVt2PQ4FU/LJb9VzebMz0cO204gaKbY/zNbRbyVuVfLHc4L2DkChxcosodeKP71OSTQv AFHXPcA8L/OEoXX+2duG4oySpgO63bYz26kMb+CX7dp1QweTDxAfepmG4NM05jL8qYlz f5sEdofAdo/uvKva4u83bcYkIr38P6mzS498bfVyosZMtQVJ27RkM9zZzBCeh6ErJRGJ p4irI5SLxmDNu4wzwHGIC6ebB855dJO93yHmHEF2a4F3nS60mWEOStoMu3i3ML6qNQOT ZD+A==
X-Gm-Message-State: AIkVDXIqvHpz/6mFa59tJ6xQbBUXaGri6BfF2EqMraaTETu8Uz0zSGFZ9XUC7oe9+4Il1h4NUDvV8mhVaU1Pmdwx
X-Received: by 10.200.52.197 with SMTP id x5mr23855886qtb.31.1485813361977; Mon, 30 Jan 2017 13:56:01 -0800 (PST)
MIME-Version: 1.0
References: <747fda8b962b4edfab70afe2af58df36@XCH-RTP-006.cisco.com> 
In-Reply-To: 
From: David Benjamin 
Date: Mon, 30 Jan 2017 21:55:51 +0000
Message-ID: 
To: Adam Langley , "Scott Fluhrer (sfluhrer)" 
Content-Type: multipart/alternative; boundary=001a1141dd42a50d3f054756e112
Archived-At: 
Cc: "" 
Subject: Re: [TLS] Question about unrecognized extension types in the TLS 1.3 client hello message
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 30 Jan 2017 21:56:05 -0000

--001a1141dd42a50d3f054756e112
Content-Type: text/plain; charset=UTF-8

On Mon, Jan 30, 2017 at 4:45 PM Adam Langley  wrote:

On Mon, Jan 30, 2017 at 1:41 PM, Scott Fluhrer (sfluhrer)
 wrote:
> My question: in TLS 1.3, if the client inserts an extension of a type that
> the server does not recognize, how must the server behave?  Is it required
> that the server just ignore the extension, or can it take some other
action
> (e.g. ignore the client hello)?

The server must ignore unknown extensions.


Here's a PR to spell this out more explicitly in the text:
https://github.com/tlswg/tls13-spec/pull/868

I could have sworn this was in there already, but apparently not? That or I
can't read.

David

--001a1141dd42a50d3f054756e112
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Mon, Jan 30, 2017 a=
t 4:45 PM Adam Langley <agl@imperialviolet.org> wrote:
On Mon, =
Jan 30, 2017 at 1:41 PM, Scott Fluhrer (sfluhrer)

<sfluhrer@cisco.com> wrote:

> My question: in TLS 1.3, if the client inserts an extension of a type =
that

> the server does not recognize, how must the server behave?=C2=A0 Is it=
 required

> that the server just ignore the extension, or can it take some other a=
ction

> (e.g. ignore the client hello)?



The server must ignore unknown extensions.

Here=
's a PR to spell this out more explicitly in the text:
https://github.com/tlswg/tls13-spec/pull=
/868

I could have sworn this was in t=
here already, but apparently not? That or I can't read.

David


--001a1141dd42a50d3f054756e112--


From nobody Tue Jan 31 00:20:34 2017
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 4F9E7120726 for ; Tue, 31 Jan 2017 00:20:33 -0800 (PST)
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 (1024-bit key) header.d=mozilla.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 SKsTKyPufhCN for ; Tue, 31 Jan 2017 00:20:31 -0800 (PST)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::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 6F456129424 for ; Tue, 31 Jan 2017 00:20:30 -0800 (PST)
Received: by mail-wm0-x22e.google.com with SMTP id r141so67752294wmg.1 for ; Tue, 31 Jan 2017 00:20:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-transfer-encoding; bh=LQ+FV0q4gdjLenzYajWaH2HL9iqvqiColYuac2xhIu0=; b=JxnrZrZNlJ6TQUtL2jxTnQl46zl5FsskBg+aa4eNTo+jtA4pBNRY6Ge3laxXll3uB+ W/OLn3p42nCFuIH+d+mSJ8l9slFNV/AYdWMR8lOJAxMOhUgE6Czhclazd1R3fPSToU0j q6fov/Be5bII+nDA3+5tHSJqj2Z+9jhPHuYRM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-transfer-encoding; bh=LQ+FV0q4gdjLenzYajWaH2HL9iqvqiColYuac2xhIu0=; b=EJcjT3hULrxsFPJOSHOtdkEimcWSFcrzxXXLKox8nnk8OSW0tGJczaj9OUG7k8gmV7 awTH+t7fB/EBt7oIbxxfqnWNDvCpAvA5vewa6Va5sVjI82Vs7GbpWh4lwmyIXLI/jT4s NA1DXYtxfbqRz9kjfrZkXISCmoKU5Yn6h6QQM+0x0hndS+nsOVvLzxTP64jFfwr8fSQI 9rj4uKwuR/O9sRB/30ko0vEq5sg6B0oky832eOb2sGt5bSsXUQ9rx/jW94I+vMST7Ujo mQnPd5Wz8m+fFx30xUnNM7F45JyuowUwqw1Jln/SeZtifHCuLi8bLXLDEw+iaAcdo49b sRGw==
X-Gm-Message-State: AIkVDXJ9svmeXC9WKXNgCBCbCMgl7fxIS63buWwH4L6Taui4dCVrY3vYQJkU11HhqRTQRFc6
X-Received: by 10.28.15.2 with SMTP id 2mr18883180wmp.66.1485850828736; Tue, 31 Jan 2017 00:20:28 -0800 (PST)
Received: from Tims-MacBook-Pro.fritz.box (x5ce3e6e7.dyn.telefonica.de. [92.227.230.231]) by smtp.gmail.com with ESMTPSA id p49sm26840403wrb.10.2017.01.31.00.20.27 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 31 Jan 2017 00:20:28 -0800 (PST)
Message-ID: <589048CA.20309@mozilla.com>
Date: Tue, 31 Jan 2017 09:20:26 +0100
From: Tim Taubert 
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: =?UTF-8?B?SGFubm8gQsO2Y2s=?= 
References: <20170127143003.36c20329@pc1>
In-Reply-To: <20170127143003.36c20329@pc1>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: tls@ietf.org
Subject: Re: [TLS] TLS 1.3 / RSA-PSS and unusual key sizes
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 31 Jan 2017 08:20:33 -0000

Hanno Böck wrote:
> Hi,
> 
> I wanted to warn people about a potential source of bugs with the
> deployment of RSA-PSS in TLS 1.3.
> 
> Usually the RSA key modulus is a multiple of 8 (2048, 4096 etc.).
> However there's no rule that RSA keys can't have other sizes.
> 
> Implementing PSS with support for arbitrary key sizes is a bit more
> complicated than implementing it for multiples of 8. I wrote the PSS
> implementation of NSS as a summer of code project a couple of years ago
> and I remember that my first implementation completely failed to
> consider this. (The fix for that never got merged afair, I informed NSS
> developers about this.)

Thanks again Hanno for bringing this to our attention. We patched it
yesterday in NSS 3.29, soon to be merged into Firefox 53.

If anyone else is about to take a look, feel free to use the official
RSA-PSS vectors I converted to SPKI/PKCS8, so you don't have to:

https://hg.mozilla.org/projects/nss/file/c61324648525/gtests/pk11_gtest/pk11_rsapss_vectors.h

- Tim


> Back then I also reported a bug in OpenSSL:
> https://rt.openssl.org/Ticket/Display.html?id=2315&user=guest&pass=guest
> 
> Long story short: It's not unlikely that there are more PSS
> implementations having problems with this.
> So I strongly recommend that all implementors of TLS 1.3 test their
> implementations for key sizes from n*8+1 to N*8+7.
> 
> Such keys are rare, but they do exist in the wild. If implementations
> failing on that get shipped widely we may see random unexplained errors
> when people start migrating to TLS 1.3 in masses.
> 
> I had actually considered proposing to change TLS 1.3 in a way that
> such keys would be simply forbidden. But I did a check on the censys
> data and there were too many of them in the wild, so I thought it
> wasn't a feasible idea.
>