Re: [TLS] Fwd: Clarification on interleaving app data and handshake records

On 15/10/15 14:00, Martin Rex wrote: > Is the particular interop problem that you want to address > caused by a necessity to really process application data and > handshake data with arbitrary interleave, > > or is it rather a problem of getting back into half-duplex operation, > i.e. a client

Re: [TLS] Fwd: Clarification on interleaving app data and handshake records

On 15/10/15 00:04, Watson Ladd wrote: > On Wed, Oct 14, 2015 at 6:43 PM, Matt Caswell <fr...@baggins.org> wrote: >> >> >> On 14/10/15 21:42, Martin Thomson wrote: >>> On 14 October 2015 at 13:29, David Benjamin <david...@chromium.org> wrote: >>>

Re: [TLS] Fwd: Clarification on interleaving app data and handshake records

On 15/10/15 00:06, Martin Thomson wrote: > On 14 October 2015 at 15:43, Matt Caswell <fr...@baggins.org> wrote: >> "highly dangerous idea" > > Wrong Martin. Oops. Sorry. > I agree that there is a need for caution, but in > reality, it's not like

Re: [TLS] Fwd: Clarification on interleaving app data and handshake records

On 14/10/15 16:44, Martin Rex wrote: > Matt Caswell wrote: >> >> Does anyone have any views on the below? > > Yup. Interleaving application & handshake records is a > highly dangerous idea (and fortunately some TLS implementations > will abort if you try). >

Re: [TLS] Fwd: Clarification on interleaving app data and handshake records

On 14/10/15 21:42, Martin Thomson wrote: > On 14 October 2015 at 13:29, David Benjamin wrote: >> If you really absolutely must support interleave and can't avoid it, I think >> it being allowed everywhere except between CCS and Finished is probably the >> closest you can

Re: [TLS] Fwd: Clarification on interleaving app data and handshake records

Hello, Does anyone have any views on the below? Thanks Matt On 30/09/15 11:06, Matt Caswell wrote: > Hi all > > I have a question on how to interpret RFC 5246 with regards to the > interleaving of app data and handshake records. > > RFC 5246 (and RFC 4346 before it) co

[TLS] Fwd: Clarification on interleaving app data and handshake records

Resending from my account that is actually subscribed to this list! Apologies if you receive this twice... Forwarded Message Subject: Clarification on interleaving app data and handshake records Date: Wed, 30 Sep 2015 11:02:55 +0100 From: Matt Caswell <m...@openssl.org> T

Re: [TLS] Wireshark Download for TLS1.3

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=12779 > > Note for TLS implementers: Wireshark supports decryption when provided > with the

Re: [TLS] supported_versions question

Oct 31, 2016 at 07:11:10PM +, David Benjamin wrote: >>> > On Mon, Oct 31, 2016 at 2:57 PM Ilari Liusvaara >>> > <ilariliusva...@welho.com> >>> > wrote: >>> > >>> > > On Mon, Oct 31, 2016 at 06:43:52PM +, Matt Caswell wrote:

Re: [TLS] supported_versions question

On 31/10/16 23:53, Dave Garrett wrote: >> I came up with some alternative wording that I think captures the discussion: >> >> https://github.com/tlswg/tls13-spec/pull/748 > > I see no reason to require servers to validate the legacy version value. > That's just excess complexity. If the extension

[TLS] supported_versions question

A few supported_versions questions: 1) What should a server do if supported_versions is received but ClientHello.legacy_version != TLS1.2? Fail the handshake, or just ignore legacy_version? 2) What should a server do if supported_versions is received, ClientHello.legacy_version == TLS1.2, but

[TLS] ClientFinished calculation following EndOfEarlyData in draft-19

In draft-19 EndOfEarlyData was changed from an alert to a handshake message. Therefore I would have expected to see it included in the calculation of the ClientFinished (where early data is accepted). However section 4.4.4 defines the verify_data as follows: verify_data =

Re: [TLS] Updated DTLS draft

On 17 March 2017 at 00:03, Martin Thomson <martin.thom...@gmail.com> wrote: > On 17 March 2017 at 10:58, Matt Caswell <fr...@baggins.org> wrote: >> In DTLS1.3 the cookie is now (potentially) much larger and appears much >> later in >> the Client

Re: [TLS] Updated DTLS draft

On 13 March 2017 at 23:41, Eric Rescorla wrote: > I have just posted a new version of the DTLS 1.3 draft, updated for > draft-19. > It's still very rough with a lot of open issues (some of which are even > noted > in the draft), and no doubt contains egregious errors. > >

Re: [TLS] draft-ietf-tls-tls13-19 posted

On 11 March 2017 at 19:28, Ilari Liusvaara wrote: > On Fri, Mar 10, 2017 at 03:34:39PM -0800, Eric Rescorla wrote: >> I just posted draft-19 at: >> >> https://tools.ietf.org/html/draft-ietf-tls-tls13-19 >> >> This draft includes all the outstanding wire format changes

Re: [TLS] draft-ietf-tls-tls13-21 posted

On 5 July 2017 at 11:35, Eric Rescorla wrote: > > Yes, that might not be a terrible idea. I'd also be open to replacing > the hashes of 0 with an n-byte length 0 string. It's a tiny paper > cut (and a wire format change), but would make things slightly simpler . I'm not entirely

Re: [TLS] draft-ietf-tls-tls13-21 posted

On 4 July 2017 at 01:01, Eric Rescorla wrote: > Hi folks, > > I just published draft-21, which incorporates the discussions we've > been having about 0-RTT replay. FYI, OpenSSL master branch is now draft-21 compliant. Matt ___ TLS

[TLS] SNI with early data

I note in draft-21 the following text: When clients use a PSK obtained externally to send early data, then the following additional information MUST be provisioned to both parties: - The TLS version number for use with this PSK - The cipher suite for use with this PSK -

Re: [TLS] SNI with early data

On 20/07/17 18:10, Benjamin Kaduk wrote: > On 07/20/2017 04:51 AM, Matt Caswell wrote: >> I note in draft-21 the following text: >> >>When clients use a PSK obtained externally to send early data, then >>the following additional information MUST be provis

Re: [TLS] draft-ietf-tls-tls13-21 posted

On 4 July 2017 at 01:01, Eric Rescorla wrote: > - Modifying the key derivation for PSKs so that each session ticket > is associated with a distinct PSK. Draft-21 says this about the ticket nonce: opaque ticket_nonce<1..255>; ... ticket_nonce A unique per-ticket

Re: [TLS] draft-ietf-tls-tls13-21 posted

On 4 July 2017 at 11:50, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > On Tue, Jul 04, 2017 at 11:25:35AM +0100, Matt Caswell wrote: >> On 4 July 2017 at 01:01, Eric Rescorla <e...@rtfm.com> wrote: >> > - Modifying the key derivation for PSKs so that each sessi

Re: [TLS] Alerts

On 10 May 2017 at 21:51, Martin Thomson <martin.thom...@gmail.com> wrote: > On 11 May 2017 at 01:21, Matt Caswell <fr...@baggins.org> wrote: >> Do we really need all of these alerts? > > NSS uses these, but in ways that I don't really understand. I think > that thi

[TLS] Alerts

Draft-20 currently contains this text in the section "Server Certificate Selection": 'If the client cannot construct an acceptable chain using the provided certificates and decides to abort the handshake, then it MUST abort the handshake with an"unsupported_certificate" alert."' However, section

Re: [TLS] Alerts

On 11 May 2017 at 21:06, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > >> On May 11, 2017, at 4:21 AM, Matt Caswell <fr...@baggins.org> wrote: >> >> If the view is that the more specific alerts are helpful, then I'd >> suggest amending the wordi

Re: [TLS] Which version to use in ClientKeyExchange when using supported_versions extension

On 22 May 2017 at 21:18, Roelof Du Toit wrote: > RFC 5246 has the following in section 7.4.7.1 (RSA-Encrypted Premaster > Secret): > > > > client_version > > The latest (newest) version supported by the client. This is > > used to detect version

Re: [TLS] TLSv1.3 Cookies

On 13 September 2017 at 17:08, Ilari Liusvaara wrote: >> > Yes, if one receives a ClientHello with both Cookie and EarlyData, one >> > can reply with a fatal alert, because that is not supposed to happen. >> >> That isn't quite the scenario I was talking about. Rather

Re: [TLS] TLSv1.3 Cookies

On 13 September 2017 at 16:12, Eric Rescorla <e...@rtfm.com> wrote: > On Wed, Sep 13, 2017 at 7:53 AM, Matt Caswell <fr...@baggins.org> wrote: >> >> I am looking at trying to implement the TLSv1.3 stateless cookie >> mechanism (in order to be able to support QU

Re: [TLS] TLSv1.3 Cookies

On 13 September 2017 at 16:11, Short, Todd <tsh...@akamai.com> wrote: > One comment below. > -- > -Todd Short > // tsh...@akamai.com > // "One if by land, two if by sea, three if by the Internet." > > On Sep 13, 2017, at 10:53 AM, Matt Caswell <fr...@baggin

Re: [TLS] TLSv1.3 Cookies

On 13 September 2017 at 16:09, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > On Wed, Sep 13, 2017 at 03:53:46PM +0100, Matt Caswell wrote: >> I am looking at trying to implement the TLSv1.3 stateless cookie >> mechanism (in order to be able to support QUIC stateless

[TLS] TLSv1.3 Cookies

I am looking at trying to implement the TLSv1.3 stateless cookie mechanism (in order to be able to support QUIC stateless retries). I am not clear how cookies are supposed to interact with early_data. Consider the scenario where a server is operating statelessly. Because there is no state each

Re: [TLS] Connection ID Draft

On 13 October 2017 at 07:31, Fossati, Thomas (Nokia - GB/Cambridge, UK) wrote: > To solve this, we'd need a place in the wire image of the record with > semantics: "I'm carrying a CID." > > In 1.2, we could use CT or version. (In 1.3, that would not be possible >

Re: [TLS] Connection ID Draft

On 03/11/17 09:28, Martin Thomson wrote: > On Fri, Nov 3, 2017 at 8:15 PM, Matt Caswell <m...@openssl.org> wrote: >> >> It was my understanding that it is precisely this sort of problem that >> this draft was attempting to address. Explicit marking would solve this. &

Re: [TLS] Connection ID Draft

On 02/11/17 23:34, Martin Thomson wrote: > On Fri, Nov 3, 2017 at 3:32 AM, Matt Caswell <m...@openssl.org> wrote: >> Just skimming this old thread...doesn't this fail in the case where the >> five tuple has been reused? In that case five_tuples.lookup will return >> an

Re: [TLS] Connection ID Draft

On 17/10/17 22:35, Martin Thomson wrote: > On Tue, Oct 17, 2017 at 9:26 PM, Fossati, Thomas (Nokia - > GB/Cambridge, UK) wrote: >> The following case (NAT box reboot) is problematic: >> >> 1. Application '1' on host A (A.1) uses DTLS+CID with application '1' on >>

Re: [TLS] Update on TLS 1.3 Middlebox Issues

On 06/11/17 14:31, Loganaden Velvindron wrote: > On Sat, Oct 7, 2017 at 12:16 AM, Eric Rescorla wrote: >> Hi folks, >> >> In Prague I mentioned that we were seeing evidence of increased >> failures with TLS 1.3 which we believed were due to middleboxes. In >> the meantime,

Re: [TLS] Universal PSKs

On 15/06/18 12:37, Nikos Mavrogiannopoulos wrote: > It feels that's this is too little too late. Implementations which > support PSKs will switch to TLS1.3 irrespective of this proposal. If > this proposal takes on, we will have some implementations which support > universal PSKs and others

[TLS] Interaction between cookies and middlebox compat mode

Consider the scenario where a server is operating statelessly (i.e. using the cookie extension) and a client is operating in middlebox compat mode. In that case the client sends an initial ClientHello and receives a ServerHello(HRR) back with a cookie in it. Before it sends its second ClientHello

Re: [TLS] Interaction between cookies and middlebox compat mode

On 28/12/17 18:06, Eric Rescorla wrote: > I must be missing your point. According to the spec as it stands even > with a stateful server I MUST ignore a CCS that comes first. Since this > is a stateful server it may end up negotiating TLSv1.2 - which requires > us to abort the

Re: [TLS] Interaction between cookies and middlebox compat mode

On 27/12/17 19:33, Eric Rescorla wrote: > > > On Wed, Dec 27, 2017 at 11:17 AM, Matt Caswell <m...@openssl.org > <mailto:m...@openssl.org>> wrote: > > Consider the scenario where a server is operating statelessly (i.e. > using the cookie ext

Re: [TLS] Interaction between cookies and middlebox compat mode

On 28/12/17 12:28, Eric Rescorla wrote: > I think it would be helpful > to be more explicit in the text if that is the case, i.e. identify the > first point in the handshake and the last point in the handshake where > CCS is valid. There probably should also be some words about

Re: [TLS] Interaction between cookies and middlebox compat mode

On 28/12/17 17:42, Eric Rescorla wrote: > > > On Thu, Dec 28, 2017 at 8:12 AM, Matt Caswell <m...@openssl.org > <mailto:m...@openssl.org>> wrote: > > > > On 28/12/17 12:28, Eric Rescorla wrote: > >     I think it would be helpful &

Re: [TLS] Interaction between cookies and middlebox compat mode

On 28/12/17 17:55, Eric Rescorla wrote: > > On Thu, Dec 28, 2017 at 9:51 AM, Matt Caswell <m...@openssl.org > <mailto:m...@openssl.org>> wrote: > > > > On 28/12/17 17:42, Eric Rescorla wrote: > > > > > > On Thu, Dec

Re: [TLS] inappropriate_fallback

On 09/08/18 13:56, Peter Gutmann wrote: > ​Eric Rescorla writes: > >> So if the server wants TLS 1.1, then it doesn't set the bytes. > > If that's the case then the text that says: > >If negotiating TLS 1.1 or below, TLS 1.3 servers MUST and TLS 1.2 >servers SHOULD set the last eight

Re: [TLS] inappropriate_fallback

On 08/08/18 14:45, Eric Rescorla wrote: > > > On Wed, Aug 8, 2018 at 6:26 AM, Matt Caswell <mailto:m...@openssl.org>> wrote: > > > > On 08/08/18 14:21, Benjamin Kaduk wrote: > > On Wed, Aug 08, 2018 at 02:05:00PM +0100, Matt Casw

Re: [TLS] inappropriate_fallback

On 08/08/18 15:01, Benjamin Kaduk wrote: > On Wed, Aug 08, 2018 at 02:52:27PM +0100, Matt Caswell wrote: >> >> >> On 08/08/18 14:45, Eric Rescorla wrote: >>> >>> >>> On Wed, Aug 8, 2018 at 6:26 AM, Matt Caswell >> <mailto:m...@openssl.org

Re: [TLS] inappropriate_fallback

On 08/08/18 15:06, Eric Rescorla wrote: > The spec is actually extremely clear on this point > https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.1.3 > > >    TLS 1.3 clients receiving a ServerHello indicating TLS

Re: [TLS] inappropriate_fallback

On 08/08/18 15:21, Eric Rescorla wrote: > > > On Wed, Aug 8, 2018 at 7:11 AM, Matt Caswell <mailto:m...@openssl.org>> wrote: > > > > On 08/08/18 15:06, Eric Rescorla wrote: > > The spec is actually extremely clear on this point > >

[TLS] Alerts after early_data

If a client has sent early_data and later encounters an error before it has sent the end of early data message, should the alert be sent in plaintext, or encrypted using the client_early_traffic secret? The error could occur before or after the client knows whether the server has accepted its

Re: [TLS] Alerts after early_data

On 08/08/18 12:13, Hubert Kario wrote: > On Tuesday, 7 August 2018 10:35:40 CEST Matt Caswell wrote: >> If a client has sent early_data and later encounters an error before it >> has sent the end of early data message, should the alert be sent in >> plaintex

[TLS] inappropriate_fallback

Draft 28 defines the inappropriate_fallback alert as follows: inappropriate_fallback Sent by a server in response to an invalid connection retry attempt from a client With the introduction of the downgrade protection sentinels it now seems that an inappropriate fallback could also be

Re: [TLS] inappropriate_fallback

On 08/08/18 14:21, Benjamin Kaduk wrote: > On Wed, Aug 08, 2018 at 02:05:00PM +0100, Matt Caswell wrote: >> Draft 28 defines the inappropriate_fallback alert as follows: >> >> inappropriate_fallback Sent by a server in response to an invalid >> connection

Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3

On 20/07/18 10:38, Eric Rescorla wrote: > The issue is not cross-protocol attacks; it's the reuse of PSKs with > different KDFs, which we don't have any analysis for and which the TLS > 1.3 document prohibits. Can you supply the reference for that prohibition? Thanks Matt

Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3

On 20/07/18 13:42, David Benjamin wrote: > I think that's the point of deciding this immediate question now, so we > can get some text in the specification. If we decide to fix this, we'd > instruct implementations to (temporary!) turn off TLS 1.3 if 1.2 PSKs > are configured and then, once the

[TLS] signature_algorithms_cert extension

The specification of the new signature_algorithms_cert seems somewhat lacking to me. There is very little description about how it should be interpreted. About the best I can get from the spec is this: The "signature_algorithms_cert" extension applies to signatures in certificates and the

[TLS] Tickets after key update/post handshake auth

What is reasonable behaviour for a client to do with any tickets it has previously received following a key update or a post-handshake authentication? Should those old tickets be now considered out-of-date and not used? Matt ___ TLS mailing list

Re: [TLS] ESNI padding the Certificate message

On 13/12/2018 13:10, Stephen Farrell wrote: > > Hiya, > > Was just adding code for this and I noticed that the draft says > a server: "SHOULD pad the Certificate message, via padding at > the record layer, such that its length equals the size of the > largest possible Certificate (message)

[TLS] Is Ed25519/Ed448 ok for use in DTLS1.2?

RFC8422 specifies the usage of Ed25519 and Ed448 in TLSv1.2. However there is barely any mention of DTLS. There is one reference which says this: "IANA has assigned one value from the "TLS HashAlgorithm" registry for Intrinsic (8) with DTLS-OK set to true (Y) and this document as reference. This

Re: [TLS] Is Ed25519/Ed448 ok for use in DTLS1.2?

On 20/11/2019 04:58, Benjamin Kaduk wrote: > Quoting from RFC 6347: > >DTLS 1.0 [DTLS1] was originally defined as a delta from [TLS11]. >This document introduces a new version of DTLS, DTLS 1.2, which is >defined as a series of deltas to TLS 1.2 [TLS12]. [...] > > The presumption

Re: [TLS] Is Ed25519/Ed448 ok for use in DTLS1.2?

On 21/11/2019 08:59, Matt Caswell wrote: > If you take the line that "anything specified for TLSv1.2 is implicitly > ok for DTLSv1.2 unless stated otherwise", then I at least think an RFC > should have a minimal nod towards DTLS. At least to give the message > that &q

Re: [TLS] Is Ed25519/Ed448 ok for use in DTLS1.2?

On 19/11/2019 00:41, Salz, Rich wrote: > As 8422 says "DTLS-OK" and since Yoav is both an author of the RFC and one of > the registry experts, I think he needs to reply here. > >>My guess is either: >>1) The registry is in error and they should not have Y against them >> or > >

Re: [TLS] Is Ed25519/Ed448 ok for use in DTLS1.2?

On 18/11/2019 22:38, Salz, Rich wrote: > Does Sesction 15 of RFC 8447 help? Not really, no. It adds some broad statements about the applicability of these registries, i.e. that they're only useful for DTLS1.2 and below, and adds some reserved fields. But it offers no explanation for where the