Re: [TLS] Last Call: <draft-ietf-tls-tls13-24.txt> (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard

[Stephen Farrell <[e-mail]>]

Just on the 0-RTT thing:

As a non-fan of 0-RTT I agree with Colm's conclusion. (Nicely
argued too btw.)

I do believe we'll live to regret 0-RTT when implementation
issues and unsuitable application uses emerge over time but
neither that nor general dislike of 0-RTT are IMO sufficient
reasons to hold TLS 1.3 at this point, given the benefits of
other aspects of TLS 1.3.

In addition, the fact of 0-RTT as an (in practice) unavoidable
part of TLS 1.3 and the implications of that were previously
raised with both the IESG and IAB in a fair amount of detail,
(about 1.5-2 years ago maybe but the issues are the same) and
IIRC at an IETF plenary as well, so this has been rehearsed
before the IETF already, even if not during a formal IETF LC.

Cheers,
S.

On 19/02/18 19:13, Colm MacCárthaigh wrote:
> Since this IETF-LC/IESG process is a good chance to get a sanity check, I'd
> like to boil down what I think are the nits and risks with 0-RTT, and if
> others want to weigh in they can. I'll state my own position at the bottom.
> 
> Broadly, I think there are three issues with 0-RTT:
> 
>    1) The TLS 1.3 draft allows for 0-RTT data, including things like
> requests and headers, to be replayed by attackers.
> 
>    2) 0-RTT data, again including requests and headers, has no
> cryptographic guarantee of forward-secrecy and will likely be protected by
> symmetric session ticket encryption keys (STEK) that can be used quite
> broadly with no limits on re-use, rotation, and rely on vendors being able
> to share and revoke keys frequently and securely. Basically: If a vendors
> STEK is compromised, than an unbounded number of end-user requests and
> headers can be decrypted. This obviously defeats the goal of achieving
> forward secrecy.
> 
>   3) While no working attack has been found, some cryptographers and
> protocol experts believe that the 0-RTT exchange is overly-complex and a
> source of risk. Kenny Paterson made the most prominent statement (
> http://bristolcrypto.blogspot.com/2017/03/pkc-2017-kenny-paterson-accepting-bets.html
> ), but I've heard it echoed at several IACR events. It is definitely true
> that 0-RTT resumption complicates the TLS state machine and creates unusual
> conditions such as needing to restart messaging sequences.
> 
> The TLS-WG was chartered with "aiming for one roundtrip for a full
> handshake and one or zero roundtrip for repeated handshakes. The aim is
> also to maintain current security features" (
> https://datatracker.ietf.org/wg/tls/charter/).  But with these 3 issues,
> there is a clearly a trade-off between security (the S in TLS) and speed.
> 
> Issue 3 is matter of judgment; my personal judgement is that we will see
> implementation bugs due to state machine complexity, but there's no
> evidence that the cryptographic and protocol semantics are not robust.
> 
> With regards to issues 1, and 2, the latest TLS draft makes it possible to
> achieve both of these aims. Through the use of single-use session tickets,
> it is possible to provide anti-replay and forward-secrecy properties for
> 0-RTT data. I'm grateful for the changes that were introduced for this.
> 
> At the same time though, most vendors have stated that they don't plan to
> do that and instead have designed around limited replay time windows,
> non-transactional strike registers, and non-forward secure tickets. This is
> what I expect to see deployed, and already see with some TLS1.3 deployment
> experiments.  TLS1.3 could be more restrictive here; limiting the size of
> session tickets to smaller than the size of session state would effectively
> forbid any kind of session encoding which would force the issue, but
> several vendors are against it because it doesn't align with current
> practices and it incurs the cost of server-size caching. For balance, in
> the last year I have heard from most vendors that they do plan to implement
> some anti-replay mitigation though, beyond the simple time-windowing, which
> goes a way to protecting users from throttle limits.
> 
> I am disappointed by the unfortunate preference for cost-saving over robust
> security. Good cryptography usually costs money, or else we'd still be
> using RC4. I do think that we will see security and correctness issues due
> to replays interacting with non-idempotent services and throttling
> configurations. While it's true that browsers can be made to replay
> requests already, there are many web and non-HTTP services that are
> certainly not tolerant of replays. Secondly, I think that it is inevitable
> that vendor security compromises will disclose troves of user requests,
> passwords, credit cards to decryption; but this is perhaps more of a
> nation-state-adversary level risk. Some more detail on attacks related to
> issues 1/ and 2/ is available in the security review of 0-RTT data:
> https://github.com/tlswg/tls13-spec/issues/1001 .
> 
> 
> After all of that, here's my own position:
> 
> I strongly support the current TLS1.3 draft progressing to RFC status. I
> work at Amazon, where one of our leadership principles is "Disagree and
> Commit" (https://www.amazon.jobs/principles); the idea is that it's
> important to make yourself heard, but also to move forward and not be
> endlessly bogged down. I've been vocal about 0-RTT risks, and certainly
> heard and understood, and those concerns have been reflected in generous
> changes to the draft. I'm happy that it's possible to build a
> forward-secret, non-repayable 0-RTT implementation and that's what I'm
> doing. I wish everyone else would too, but that's not consensus; others
> have a different weighting for the trade-offs between speed, security and
> cost and those views are also legitimate.
> 
> But my more important reason for supporting is that overall TLS1.3 is much
> much better than TLS1.2, including in regards to forward-secrecy, which is
> now guaranteed for all non-0RTT data. I still believe that it will
> meaningfully increase the overall security posture for the internet, and
> I'm super excited to get it out and for users to be getting the benefits.
> TLS has always been a bit of a mess, it's not as clean as something
> designed by a single voice focused on modern cryptographic best-practices,
> but 1.3 does a lot of good cleaning up. Shipping 1.3 doesn't mean things
> can't be improved further, and delay inflicts 1.2 and lower versions on
> users for even longer. So let's go!
> 
> 
> On Mon, Feb 19, 2018 at 7:58 AM, Kathleen Moriarty <
> [e-mail]> wrote:
> 
>> Dear Yuhong,
>>
>> As the sponsoring Area Director, my job is to take the draft forward
>> as was determined by working group consensus.  Like Stephen, I'm also
>> not particularly happy about the choice to leave in 0-RTT, but I have
>> to support it as a WG decision.  Whatever the version number in the
>> ServerHello decision is from the WG, I will support that decision.
>> The ServerHello decision doesn't really fall into the, "arms race" as
>> you put it.  More on that in another thread.
>>
>> Best regards,
>> Kathleen
>>
>> On Thu, Feb 15, 2018 at 9:04 PM, Yuhong Bao <[e-mail]>
>> wrote:
>>> I wonder what is IESG's opinion on the TLS arms race with middleboxes.
>>> Yes, I am talking about moving the version number in the ServerHello.
>>>
>>> ________________________________________
>>> From: TLS <[e-mail]> on behalf of The IESG <
>> [e-mail]>
>>> Sent: Thursday, February 15, 2018 1:13:48 PM
>>> To: IETF-Announce
>>> Cc: [e-mail]; [e-mail]; [e-mail]
>>> Subject: [TLS] Last Call: <draft-ietf-tls-tls13-24.txt> (The Transport
>> Layer Security (TLS) Protocol Version 1.3) to Proposed Standard
>>>
>>>
>>> The IESG has received a request from the Transport Layer Security WG
>> (tls) to
>>> consider the following document: - 'The Transport Layer Security (TLS)
>>> Protocol Version 1.3'
>>>   <draft-ietf-tls-tls13-24.txt> as Proposed Standard
>>>
>>> The IESG plans to make a decision in the next few weeks, and solicits
>> final
>>> comments on this action. Please send substantive comments to the
>>> [e-mail] mailing lists by 2018-03-01. Exceptionally, comments may
>> be
>>> sent to [e-mail] instead. In either case, please retain the
>> beginning of
>>> the Subject line to allow automated sorting.
>>>
>>> Abstract
>>>
>>>
>>>    This document specifies version 1.3 of the Transport Layer Security
>>>    (TLS) protocol.  TLS allows client/server applications to communicate
>>>    over the Internet in a way that is designed to prevent eavesdropping,
>>>    tampering, and message forgery.
>>>
>>>
>>>
>>>
>>> The file can be obtained via
>>> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/
>>>
>>> IESG discussion can be tracked via
>>> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ballot/
>>>
>>> The following IPR Declarations may be related to this I-D:
>>>
>>>    https://datatracker.ietf.org/ipr/2900/
>>>
>>>
>>>
>>> The document contains these normative downward references.
>>> See RFC 3967 for additional information:
>>>     rfc8017: PKCS #1: RSA Cryptography Specifications Version 2.2
>> (Informational - IETF stream)
>>>
>>>
>>>
>>> _______________________________________________
>>> TLS mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>> _______________________________________________
>>> TLS mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>>
>>
> 
> 
> 
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
> 

-- 
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)