Subject: [Uta] is it time for 7525bis?

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 17 Apr 2018 09:22:54 -0600

During ART-ART and IESG review of draft-ietf-tram-stunbis, we realized
that just pointing to RFC 7525 might not be enough anymore, now that the
TLS 1.3 spec has been approved for publication. 7525bis, anyone?

Peter

-------- Forwarded Message --------
Subject: Re: Artart telechat review of draft-ietf-tram-stunbis-16
Date: Tue, 17 Apr 2018 09:11:28 -0600
From: Peter Saint-Andre <[email-masked]>
To: Marc Petit-Huguenin <[email-masked]>, Eric Rescorla <[email-masked]>
CC: [email-masked], [email-masked], IETF discussion
list <[email-masked]>, [email-masked]

On 4/17/18 4:02 AM, Marc Petit-Huguenin wrote:
> 
> On 04/16/2018 08:12 PM, Eric Rescorla wrote:
>> On Mon, Apr 16, 2018 at 5:22 PM, Peter Saint-Andre <[email-masked]>
>> wrote:
>>
>>> Hi Marc, a few further comments inline.
>>>
>>> On 4/16/18 5:43 PM, Marc Petit-Huguenin wrote:
>>>> Hi Peter,
>>>>
>>>> Thanks for the review and sorry for the delay in responding, I was
>>> traveling for the last 4 weeks.
>>>>
>>>> See my responses inline.
>>>>
>>>> On 04/02/2018 03:59 PM, Peter Saint-Andre wrote:
>>>>> Reviewer: Peter Saint-Andre
>>>>> Review result: Ready with Nits
>>>>>
>>>
>>> <snip/>
>>>
>>>>> The first paragaraph of Section 6.2.3 restates recommendations from RFC
>>>>> 7525; why not simply reference that specification?
>>>>
>>>> The original text in RFC5389 said this:
>>>>
>>>> " When STUN is run by itself over TLS-over-TCP, the
>>>>   TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be implemented at a
>>>>   minimum. [...]"
>>>>
>>>> The new text is an attempt at updating it in the same spirit of giving
>>> minimal instructions and complementing them with a reference to RFC 7525 -
>>> which was the reason for the reference to RFC 7525 there.
>>>>
>>>> So I kept the text there, followed by the following paragraph, in
>>> addition of moving the original last paragraph in the Security
>>> Consideration section:
>>>>
>>>> " These recommendations are just a part of the the recommendations in
>>>>   [RFC7525] that implementations and deployments of a STUN usage using
>>>>   TLS or DTLS SHOULD follow."
>>>
>>> I would instead suggest that we do something like Section 2 of RFC 7590
>>> for XMPP:
>>>
>>>    The best current practices documented in the "Recommendations for
>>>    Secure Use of TLS and DTLS" [RFC7525] are included here by reference.
>>>    Instead of repeating those recommendations here, this document mostly
>>>    provides supplementary information regarding secure implementation
>>>    and deployment of XMPP technologies.
>>>
>>> Here's the rationale: RFC 7525 is likely to be updated/replaced more
>>> quickly than STUNbis. If STUNbis recommends a particular cipher suite
>>> that 7525bis stops recommending, in the absence of STUNter will STUN
>>> implementations keep following STUNbis or will they upgrade to whatever
>>> 7525bis recommends? I suggest it will be the former, which is not what
>>> we want.
>>>
>>
>> I forgot about this in my review, but you should also profile ciphers for
>> TLS 1.3.
>>
>> -Ekr
>>
> 
> Do you have any suggestion for these, or a pointer to a document that I can use to find these?

Off-topic: it sounds like we might need to start work on 7525bis...

Peter

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 17 Apr 2018 11:25:41 -0400

> On Apr 17, 2018, at 11:22 AM, Peter Saint-Andre <[email-masked]> wrote:
> 

Is TLS 1.3 already best-practice?  It might take some time before all
the early interoperability and deployment barriers are shaken out...

-- 
	Viktor.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 17 Apr 2018 09:39:16 -0600

> the early interoperability and deployment barriers are shaken out...

Deployment is happening quite quickly. I agree on smoothing out any
kinks (and DTLS 1.3 is still under development), but we might want to
provide recommendations about cipher suites as soon as practicable. And
note that we started work on the Internet-Draft that became RFC 7525
over 18 months before publication. Hopefully it will not take us as long
this time. Anyway, it's something for this group to keep an eye on and
likely revisit before the end of the year if not sooner.

Peter

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 17 Apr 2018 15:41:15 +0000

>    provide recommendations about cipher suites as soon as practicable. And

Let's not do that.  One of the things about TLS 1.3 is that it defines just six cipher suites.  There is no need to profile them.

But yes, we should watch and be ready with a two-page update. :)

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 17 Apr 2018 09:52:03 -0600

> But yes, we should watch and be ready with a two-page update. :)

Lots of RFCs point to RFC 7525 (actually BCP 195) instead of rolling
their own. Making sure BCP 195 is up to date is a good thing. :-)

I'll talk with my co-authors.

Peter

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Apr 2018 22:37:44 +0100

> TLS 1.3 spec has been approved for publication. 7525bis, anyone?

I also think it's a bit early, but no harm to start the
work, as long as it's not rushed. I'd say it'll be a while
before e.g. we see some of the 0rtt car-crashes that it'd
be good to advise against;-)

S.

> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 18 Apr 2018 14:13:04 -0600

> be good to advise against;-)

Waiting until DTLS 1.3 is finished seems like a good idea.

As to car crashes, that's not the job of 7525bis - if there are problems
with 0rtt, someone needs to fix TLS, not the guidelines for using it.

Peter

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 18 Apr 2018 21:39:25 +0100

Hiya,

> Waiting until DTLS 1.3 is finished seems like a good idea.

Agreed.

> with 0rtt, someone needs to fix TLS, not the guidelines for using it.

Disagree. 0rtt will (IMO, crystal balling:-) be used unsafely
by some folks. Assuming that we won't end up with consensus to
remove the feature from TLS1.3, then I do think it'd be right
to document what we know about (un)safely using 0rtt at the
time BCP195 is being updated. RFC7525 includes similar text
e.g. about session resumption (in section 3.4).

But... we can safely hold off on resolving that potential
disagreement until the relevant work is under way.

Cheers,
S.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 18 Apr 2018 14:45:43 -0600

> e.g. about session resumption (in section 3.4).

Maaaybe. ;-)

> disagreement until the relevant work is under way.

I am looking forward to it already!

Peter

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 18 Apr 2018 22:37:30 -0400

> On Apr 18, 2018, at 4:39 PM, Stephen Farrell <[email-masked]> wrote:
> 

And for TLS 1.3 interoperability to be sorted out with the passage of time.

I noted in the thread about SNI and MTA-STS, the present behaviour of Google's
TLS stack is blatently pedantic in a non-interoperable way when clients omit
SNI (which they may do).

-- 
	Viktor.