Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-grease-03: (with COMMENT)

[Mirja Kuehlewind]

Thanks!

> On 21. Aug 2019, at 23:34, David Benjamin 
>  wrote:
> 
> On Mon, Aug 19, 2019 at 3:51 AM Mirja Kuehlewind  wrote:
> Hi David,
> 
> 
> > On 16. Aug 2019, at 18:16, David Benjamin 
> >  wrote:
> > 
> > On Fri, Aug 16, 2019 at 3:39 AM Mirja Kuehlewind  
> > wrote:
> > > >> One comment/question: I think I didn't quite understand what a client 
> > > >> is
> > > >> supposed to do if the connection fails with use of greasing values...? 
> > > >> The
> > > >> security considerations seems to indicate that you should not try to 
> > > >> re-connect
> > > >> without use of grease but rather just fail completely...? Also should 
> > > >> you cache
> > > >> the information that greasing failed maybe?
> > > > 
> > > > I'll let the authors chime in, but I think the sense of the security
> > > > considerations is more that we are preventing the fallback from being
> > > > needed "in production due to "real" negotiation failures.  Falling back 
> > > > on
> > > > GREASE failure is not as bad, provided that you follow-up with the 
> > > > failing
> > > > peer out of band to try to get it fixed.
> > > > I don't know how much value there would be in caching the 
> > > > grease-intolerate
> > > > status; ideally it would almost-never happen.
> > > 
> > > Okay, then I think it would be nice to say something more in the 
> > > document, about fallback at least.
> > > 
> > > Ben's description is right. If deploying a new TLS feature results in too 
> > > many interop failures with existing buggy servers, that feature becomes 
> > > difficult to deploy and there is a lot of pressure to apply some sort of 
> > > mitigation like a fallback. That's no good. GREASE's goal is to avoid the 
> > > interop failures to begin with. The text was not meant to imply that you 
> > > should do any sort of fallback.
> > > 
> > > What change did you have in mind? The current text says:
> > > 
> > > > Historically, when interoperability problems arise in deploying new TLS 
> > > > features, implementations have used a fallback retry on error with the 
> > > > feature disabled. This allows an active attacker to silently disable 
> > > > the new feature. By preventing a class of such interoperability 
> > > > problems, GREASE reduces the need for this kind of fallback.
> > > 
> > > That reads to me as describing historical fallbacks, rather than 
> > > recommending new ones. (Indeed you shouldn't do fallbacks. Fallbacks are 
> > > bad.. They break downgrade protection.)
> > 
> > I was thinking about adding some new text somewhere else in the document 
> > that give a recommendation if you should fallback on grease and when.
> > 
> > I mean, the answer to that is "don't" and "never", just as is unstatedly 
> > true for any other TLS extension. TLS's downgrade protection doesn't work 
> > if you do fallbacks. While downgrading from GREASE doesn't matter per se, 
> > it defeats the purpose, so the usual rules for TLS apply.
> 
> 
> For me this wasn’t clear because this is not just a “normal” extension. If 
> you want to be sure that it is clear to everybody, you should write it down 
> in the draft. However, that my view and this was a just a comment to 
> consider, so the authors (and group) need to decide.
> 
> Fair enough. I've added the following to that paragraph in my local copy.
> 
>  Implementations SHOULD
>  NOT retry with GREASE disabled on connection failure. While allowing an
>  attacker to disable GREASE is unlikely to have immediate security
>  consequences, such a fallback would prevent GREASE from defending against
>  extensibility failures.
> 
> I'll upload it as -04 after all the comments come in. 

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

Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-grease-03: (with COMMENT)

[David Benjamin]

On Wed, Aug 21, 2019 at 11:18 PM Roman Danyliw  wrote:

>
>
> > -Original Message-
> > From: Martin Thomson [mailto:m...@lowentropy.net]
> > Sent: Wednesday, August 21, 2019 8:02 PM
> > To: David Benjamin ; Roman
> > Danyliw 
> > Cc: draft-ietf-tls-gre...@ietf.org;  ; The
> IESG
> > ; tls-chairs 
> > Subject: Re: [TLS] Roman Danyliw's No Objection on
> draft-ietf-tls-grease-03:
> > (with COMMENT)
> >
> > On Thu, Aug 22, 2019, at 07:44, David Benjamin wrote:
> > >  That clause was meant to be descriptive of the other bits of the
> > > document. "[Such-and-such] may not be [such-and-such]ed, so [some
> > > consequence of this]". Using "must not" reads odd to me: "GREASE
> > > values must not be negotiated, so they do not directly impact the
> > > security of TLS connections."
> >
> > Perhaps what you are looking for is "cannot": "GREASE values cannot be
> > negotiated, ..."
>
> A "cannot" would make sense to me.
>

"cannot" it is! :-)

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

Re: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3

[Paul Yang]

Hi there,

Just to keep the it consistent with what previous email said - the Markdown 
file of the draft has been pushed to the repo:

https://github.com/alipay/tls13-sm-spec 


Please check:

https://github.com/alipay/tls13-sm-spec/blob/master/BUILD.md 


for detailed information.

Thanks.

> On Aug 19, 2019, at 10:57 PM, Blumenthal, Uri - 0553 - MITLL 
>  wrote:
> 
> >  A side note: we will also upload the Markdown file of this draft into the 
> > same git
> >  repository at https://github.com/alipay/tls13-sm-spec 
>  later to make it a totally
> >  public involved progress.
> 
> I think this is exactly what was needed/asked-for. Thank you!
> 
> 
>> On Aug 19, 2019, at 7:51 PM, Kepeng Li > > wrote:
>> 
>> Currently, we uploaded some of the referenced documents here:
>> https://github.com/alipay/tls13-sm-spec 
>> 
>> 
>> @Rene, Parts 1 and 3 can be found in the link above.
>> 
>> Hope it helps.
>> 
>> Thanks,
>> 
>> Kind Regards
>> Kepeng
>> 
>>> --
>>> 发件人：李克鹏(易深) mailto:kepeng@antfin.com>>
>>> 发送时间：2019年8月19日(星期一) 17:38
>>> 收件人：sean+ietf mailto:sean+i...@sn3rd.com>>; joe 
>>> mailto:j...@salowey.net>>; caw >> >
>>> 抄　送：tls@ietf.org  >> >; "Blumenthal, Uri - 0553 - MITLL" >> >; Paul Yang 
>>> >> >
>>> 主　题：Re: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3
>>> 
>>> Hi WG chairs,
>>> 
>>> Can we place the referenced documents in the TLS WG GitHub?
>>> https://github.com/tlswg 
>>> 
>>> According to the discussion below, this can help people to read and 
>>> understand the referenced specifications.
>>> 
>>> Thanks,
>>> 
>>> Kind Regards
>>> Kepeng
>>> 
>>> 发件人: TLS mailto:tls-boun...@ietf.org>> 代表 
>>> "Blumenthal, Uri - 0553 - MITLL" mailto:u...@ll.mit.edu>>
>>> 日期: 2019年8月18日 星期日 22:08
>>> 收件人: Paul Yang >> >
>>> 抄送: "tls@ietf.org " >> >
>>> 主题: Re: [TLS] (offline) Re: Draft for SM cipher suites used in TLS1.3
>>> 
>>> IMHO, placing the documents on GitHub would be perfect, and quite 
>>> sufficient.
>>> 
>>> Please make sure to post the name of the repo here. ;/)
>>> 
>>> I leave it to others to decide whether they'd want copies of today PDF 
>>> files sent to the mailing list directly.
>>> 
>>> Regards,
>>> Uri
>>> 
>>> Sent from my iPhone
>>> 
>>> On Aug 17, 2019, at 01:03, Paul Yang 
>>> >> > wrote:
>>> 
>>> Good points.
>>> 
>>> The good news is that we have found some English PDFs of SM2, including the 
>>> missing part 1 and part 3. Will continue to find English translations of 
>>> other SM standards mentioned in the draft.
>>> 
>>> So, if we host a free website, say on Github or so, to provide those docs, 
>>> is it convenient for you guys? Or should we just drop the   PDF files to 
>>> this mailing list as attachments?
>>> 
>>> 
>>> On Aug 16, 2019, at 10:58 PM, Rene Struik >> > wrote:
>>> 
>>> Arguably, "national" crypto specifications garnish more stature if these 
>>> are made available to the pubic by that standard-setting body itself (who, 
>>> thereby, acts as its authoritative source), without deference to a third 
>>> party (that may, independently from the originator, enforce document 
>>> control [e.g., by effectuating technical changes or enforcing controlled 
>>> dissemination]).
>>> 
>>> Since your draft introducing SM cipher suites with TLS1.3 appeals to the 
>>> authority of a standard-setting authority, easy availability of the full 
>>> and accredited technical documentation to the IETF community helps in 
>>> scrutiny and, e.g., evaluating claims in the security considerations 
>>> section.
>>> 
>>> On 8/16/2019 3:06 AM, Kepeng Li wrote:
>>> Hi Rene and all,
>>> 
>>> > Since the ISO documents are not available to the general
>>> > public without payment, it would be helpful to have a freely available
>>> > document (in English) from an authoritative source. Having such a
>>> > reference available would be helpful to the IETF community (and
>>> > researchers).
>>> About the references to ISO documens, I think it is a general issue for 
>>> IETF drafts.
>>> 
>>> How does the other IETF drafts make the references to ISO documents? ISO 
>>> documents are often referenced by IETF drafts.
>>> 
>>> Thanks,
>>> 
>>> Kind Regards
>>> Kepeng
>>> ——
>>> Re: [TLS] Draft for SM cipher suites used in TLS1.3
>>> 
>>> Rene Struik mailto:rstruik@gmail.com>> Thu, 15 
>>> August 2019 15:

[TLS] I-D Action: draft-ietf-tls-grease-04.txt

[internet-drafts]

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

Title   : Applying GREASE to TLS Extensibility
Author  : David Benjamin
Filename: draft-ietf-tls-grease-04.txt
Pages   : 12
Date: 2019-08-22

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 to ensure peers correctly handle unknown values.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-grease-04
https://datatracker.ietf.org/doc/html/draft-ietf-tls-grease-04

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


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

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

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

Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-grease-03: (with COMMENT)

[David Benjamin]

On Thu, Aug 22, 2019 at 3:48 AM Mirja Kuehlewind 
wrote:

> Thanks!
>
> > On 21. Aug 2019, at 23:34, David Benjamin  40google@dmarc.ietf.org> wrote:
> >
> > On Mon, Aug 19, 2019 at 3:51 AM Mirja Kuehlewind 
> wrote:
> > Hi David,
> >
> >
> > > On 16. Aug 2019, at 18:16, David Benjamin
>  wrote:
> > >
> > > On Fri, Aug 16, 2019 at 3:39 AM Mirja Kuehlewind 
> wrote:
> > > > >> One comment/question: I think I didn't quite understand what a
> client is
> > > > >> supposed to do if the connection fails with use of greasing
> values...? The
> > > > >> security considerations seems to indicate that you should not try
> to re-connect
> > > > >> without use of grease but rather just fail completely...? Also
> should you cache
> > > > >> the information that greasing failed maybe?
> > > > >
> > > > > I'll let the authors chime in, but I think the sense of the
> security
> > > > > considerations is more that we are preventing the fallback from
> being
> > > > > needed "in production due to "real" negotiation failures.  Falling
> back on
> > > > > GREASE failure is not as bad, provided that you follow-up with the
> failing
> > > > > peer out of band to try to get it fixed.
> > > > > I don't know how much value there would be in caching the
> grease-intolerate
> > > > > status; ideally it would almost-never happen.
> > > >
> > > > Okay, then I think it would be nice to say something more in the
> document, about fallback at least.
> > > >
> > > > Ben's description is right. If deploying a new TLS feature results
> in too many interop failures with existing buggy servers, that feature
> becomes difficult to deploy and there is a lot of pressure to apply some
> sort of mitigation like a fallback. That's no good. GREASE's goal is to
> avoid the interop failures to begin with. The text was not meant to imply
> that you should do any sort of fallback.
> > > >
> > > > What change did you have in mind? The current text says:
> > > >
> > > > > Historically, when interoperability problems arise in deploying
> new TLS features, implementations have used a fallback retry on error with
> the feature disabled. This allows an active attacker to silently disable
> the new feature. By preventing a class of such interoperability problems,
> GREASE reduces the need for this kind of fallback.
> > > >
> > > > That reads to me as describing historical fallbacks, rather than
> recommending new ones. (Indeed you shouldn't do fallbacks. Fallbacks are
> bad.. They break downgrade protection.)
> > >
> > > I was thinking about adding some new text somewhere else in the
> document that give a recommendation if you should fallback on grease and
> when.
> > >
> > > I mean, the answer to that is "don't" and "never", just as is
> unstatedly true for any other TLS extension. TLS's downgrade protection
> doesn't work if you do fallbacks. While downgrading from GREASE doesn't
> matter per se, it defeats the purpose, so the usual rules for TLS apply.
> >
> >
> > For me this wasn’t clear because this is not just a “normal” extension.
> If you want to be sure that it is clear to everybody, you should write it
> down in the draft. However, that my view and this was a just a comment to
> consider, so the authors (and group) need to decide.
> >
> > Fair enough. I've added the following to that paragraph in my local copy.
> >
> >  Implementations SHOULD
> >  NOT retry with GREASE disabled on connection failure. While
> allowing an
> >  attacker to disable GREASE is unlikely to have immediate security
> >  consequences, such a fallback would prevent GREASE from defending
> against
> >  extensibility failures.
> >
> > I'll upload it as -04 after all the comments come in.
>

Uploaded:
https://www.ietf.org/rfcdiff?url1=draft-ietf-tls-grease-03&url2=draft-ietf-tls-grease-04
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls