Re: [TLS] supported_versions question

[Dave Garrett]

On Monday, October 31, 2016 08:05:59 pm Matt Caswell wrote:
> 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 is there, then it should 
> > take absolute precedence. If not, use the old system. Nothing will have a 
> > higher value there except old probers.
> 
> If legacy_version == 0x0302 (TLS1.1), but highest supported_version is
> 0x0303 (TLS1.2) - or vice versa, which client_version should be used
> in an RSA key exchange calculation?

Why would this ever happen? What client is offering to support TLS 1.1 via the 
ClientHello field but offers only TLS 1.2 via the TLS 1.3 extension? This is a 
very contrived implementation error; if you need to account for it, abort the 
connection with an error. As to the vice versa, dropping 1.0/1.1 support from 
the extension avoids that.

The simplest route here is to always use the extension if it exists, and use 
the legacy value if not. With 1.0/1.1 removed from the extension, that means 
that 1.0/1.1 cannot be negotiated with the extension, which I see as fine; 
they'll only be negotiated with servers that don't support the extension. (the 
theoretical case of a server wanting to negotiate 1.0/1.1 with a client using 
the extension is not one worth supporting; 1.2+ or bust is reasonable, here)


Dave

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

Re: [TLS] supported_versions question

[Matt Caswell]

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 is there, then it should take 
> absolute precedence. If not, use the old system. Nothing will have a higher 
> value there except old probers.

If legacy_version == 0x0302 (TLS1.1), but highest supported_version is
0x0303 (TLS1.2) - or vice versa, which client_version should be used
in an RSA key exchange calculation?

Matt

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

Re: [TLS] supported_versions question

[Dave Garrett]

On Monday, October 31, 2016 07:26:30 pm Matt Caswell wrote:
> On 31 October 2016 at 23:13, David Benjamin  wrote:
> > On Mon, Oct 31, 2016 at 6:34 PM Kurt Roeckx  wrote:
> >>
> >> On Mon, Oct 31, 2016 at 07:11:10PM +, David Benjamin wrote:
> >> > On Mon, Oct 31, 2016 at 2:57 PM Ilari Liusvaara
> >> > 
> >> > wrote:
> >> >
> >> > > On Mon, Oct 31, 2016 at 06:43:52PM +, Matt Caswell wrote:
> >> > > > 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?
> >> > >
> >> > > If legacy_version > TLS1.2, the spec requires server to ignore
> >> > > legacy_version.
> >> > >
> >> > > The case where legacy_version < TLS1.2 IIRC isn't specified, but
> >> > > ignoring legacy_version is reasonable in this case too.
> >> > >
> >> > > > 2) What should a server do if supported_versions is received,
> >> > > > ClientHello.legacy_version == TLS1.2, but supported_versions does
> >> > > > not
> >> > > > contain TLS1.3 or TLS1.2 (e.g. it contains TLS1.1 or below)? Fail
> >> > > > the
> >> > > > handshake, use the legacy_version, or use use the versions in
> >> > > > supported_versions?
> >> > >
> >> > > There's also the case where supported_versions has TLS 1.1 and TLS
> >> > > 1.4,
> >> > > the latter the server has never heard about...
> >> > >
> >> > > > 3) If the answer to (2) above is ignore the legacy_version, and just
> >> > > > use the versions in supported_versions, which client_version should
> >> > > > be
> >> > > > used in the RSA pre-master secret calculation? The one in
> >> > > > legacy_version, or the highest one in supported_versions? Presumably
> >> > > > it has to be the one in legacy_version, otherwise thing will fail
> >> > > > when
> >> > > > the client talks to a server that doesn't understand
> >> > > > supported_versions?
> >> > >
> >> > > Yeah, I presume putting the version in legacy_version is the only sane
> >> > > thing to do. But causes other problems with downgrade protection.
> >> > >
> >> > > OTOH, RSA key exchange is known to be very broken and is affected by
> >> > > all kinds of downgrade (and other) attacks. So if one wants actual
> >> > > security, it needs to be removed.
> >> > >
> >> >
> >> > We could say the versions extension only applies to 1.2 and up. I.e.
> >> > don't
> >> > bother advertising 1.1 and 1.0 as a client and servers ignore 1.1 and
> >> > 1.0
> >> > when they see them in the version list. That keeps the protocol
> >> > deployable
> >> > on the Internet as it exists, avoids having to evaluate too versioning
> >> > schemes (if you see the extension, you don't bother reading
> >> > legacy_version
> >> > at all), while avoiding the weird behavior where, given this
> >> > ClientHello:
> >> >
> >> >legacy_version: TLS 1.2
> >> >supported_versions: {TLS 1.1}
> >> >
> >> > TLS 1.3 says to negotiate TLS 1.1 and TLS 1.2 says to negotiate TLS 1.2.
> >>
> >> So I guess you're also saying that a server that implements TLS
> >> 1.1 to TLS 1.3, but disables TLS 1.2 and TLS 1.3 support should
> >> ignore the supported_versions even when it knows about it?
> >>
> >> I guess I have same questions but with only TLS 1.3 disabled, to
> >> be sure when we need to look at it.
> >
> >
> > Hrm, actually I hadn't thought of that. Yeah, I guess a server which
> > disables versions must then gate supported_version handling on whether TLS
> > 1.3 is enabled. That's not a dealbreaker, but is certainly additional
> > gnarliness.
> >
> > (Our current implementation just processes the extension uncondtionally, but
> > we'll also happily negotiate old versions out of it.)
> 
> 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 is there, then it should take absolute 
precedence. If not, use the old system. Nothing will have a higher value there 
except old probers.

Ditching TLS 1.0/1.1 from the extension sounds fine, though. There's not going 
to be any servers accepting this extension that won't negotiate 1.2+.


Dave

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

Re: [TLS] supported_versions question

[Matt Caswell]

On 31 October 2016 at 23:35, Eric Rescorla  wrote:
> Our current implementation also processes the extension unconditionally.
>
> I'm not convinced that this represents an improvement, both for the reason
> that Kurt
> indicates and just in terms of simplicity of story. The current design is
> simply
> "if supported_versions is present, then use it", whereas trying to clip it
> on 1.2
> is inherently more complicated. I'm not particularly bothered by the anomaly
> that David mentions between legacy_version and supported_versions,
> especially
> given that we're perfectly happy to tolerate deviation the other way.

My biggest concern is that there are a number of corner cases here
where it is unclear what to do because the current wording doesn't
specify it (see my original questions at the start of this thread).
Like, I said earlier, it could be made to work If retaining 
> -Ekr
>
>
> On Mon, Oct 31, 2016 at 4:13 PM, David Benjamin 
> wrote:
>>
>> On Mon, Oct 31, 2016 at 6:34 PM Kurt Roeckx  wrote:
>>>
>>> On Mon, Oct 31, 2016 at 07:11:10PM +, David Benjamin wrote:
>>> > On Mon, Oct 31, 2016 at 2:57 PM Ilari Liusvaara
>>> > 
>>> > wrote:
>>> >
>>> > > On Mon, Oct 31, 2016 at 06:43:52PM +, Matt Caswell wrote:
>>> > > > 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?
>>> > >
>>> > > If legacy_version > TLS1.2, the spec requires server to ignore
>>> > > legacy_version.
>>> > >
>>> > > The case where legacy_version < TLS1.2 IIRC isn't specified, but
>>> > > ignoring legacy_version is reasonable in this case too.
>>> > >
>>> > > > 2) What should a server do if supported_versions is received,
>>> > > > ClientHello.legacy_version == TLS1.2, but supported_versions does
>>> > > > not
>>> > > > contain TLS1.3 or TLS1.2 (e.g. it contains TLS1.1 or below)? Fail
>>> > > > the
>>> > > > handshake, use the legacy_version, or use use the versions in
>>> > > > supported_versions?
>>> > >
>>> > > There's also the case where supported_versions has TLS 1.1 and TLS
>>> > > 1.4,
>>> > > the latter the server has never heard about...
>>> > >
>>> > > > 3) If the answer to (2) above is ignore the legacy_version, and
>>> > > > just
>>> > > > use the versions in supported_versions, which client_version should
>>> > > > be
>>> > > > used in the RSA pre-master secret calculation? The one in
>>> > > > legacy_version, or the highest one in supported_versions?
>>> > > > Presumably
>>> > > > it has to be the one in legacy_version, otherwise thing will fail
>>> > > > when
>>> > > > the client talks to a server that doesn't understand
>>> > > > supported_versions?
>>> > >
>>> > > Yeah, I presume putting the version in legacy_version is the only
>>> > > sane
>>> > > thing to do. But causes other problems with downgrade protection.
>>> > >
>>> > > OTOH, RSA key exchange is known to be very broken and is affected by
>>> > > all kinds of downgrade (and other) attacks. So if one wants actual
>>> > > security, it needs to be removed.
>>> > >
>>> >
>>> > We could say the versions extension only applies to 1.2 and up. I.e.
>>> > don't
>>> > bother advertising 1.1 and 1.0 as a client and servers ignore 1.1 and
>>> > 1.0
>>> > when they see them in the version list. That keeps the protocol
>>> > deployable
>>> > on the Internet as it exists, avoids having to evaluate too versioning
>>> > schemes (if you see the extension, you don't bother reading
>>> > legacy_version
>>> > at all), while avoiding the weird behavior where, given this
>>> > ClientHello:
>>> >
>>> >legacy_version: TLS 1.2
>>> >supported_versions: {TLS 1.1}
>>> >
>>> > TLS 1.3 says to negotiate TLS 1.1 and TLS 1.2 says to negotiate TLS
>>> > 1.2.
>>>
>>> So I guess you're also saying that a server that implements TLS
>>> 1.1 to TLS 1.3, but disables TLS 1.2 and TLS 1.3 support should
>>> ignore the supported_versions even when it knows about it?
>>>
>>> I guess I have same questions but with only TLS 1.3 disabled, to
>>> be sure when we need to look at it.
>>
>>
>> Hrm, actually I hadn't thought of that. Yeah, I guess a server which
>> disables versions must then gate supported_version handling on whether TLS
>> 1.3 is enabled. That's not a dealbreaker, but is certainly additional
>> gnarliness.
>>
>> (Our current implementation just processes the extension uncondtionally,
>> but we'll also happily negotiate old versions out of it.)
>>
>> David
>>
>> ___
>> 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
>

___
TLS mailing list
TLS@ietf.org

Re: [TLS] supported_versions question

[Eric Rescorla]

Our current implementation also processes the extension unconditionally.

I'm not convinced that this represents an improvement, both for the reason
that Kurt
indicates and just in terms of simplicity of story. The current design is
simply
"if supported_versions is present, then use it", whereas trying to clip it
on 1.2
is inherently more complicated. I'm not particularly bothered by the anomaly
that David mentions between legacy_version and supported_versions,
especially
given that we're perfectly happy to tolerate deviation the other way.

-Ekr


On Mon, Oct 31, 2016 at 4:13 PM, David Benjamin 
wrote:

> On Mon, Oct 31, 2016 at 6:34 PM Kurt Roeckx  wrote:
>
> On Mon, 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:
> > > > 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?
> > >
> > > If legacy_version > TLS1.2, the spec requires server to ignore
> > > legacy_version.
> > >
> > > The case where legacy_version < TLS1.2 IIRC isn't specified, but
> > > ignoring legacy_version is reasonable in this case too.
> > >
> > > > 2) What should a server do if supported_versions is received,
> > > > ClientHello.legacy_version == TLS1.2, but supported_versions does not
> > > > contain TLS1.3 or TLS1.2 (e.g. it contains TLS1.1 or below)? Fail the
> > > > handshake, use the legacy_version, or use use the versions in
> > > > supported_versions?
> > >
> > > There's also the case where supported_versions has TLS 1.1 and TLS 1.4,
> > > the latter the server has never heard about...
> > >
> > > > 3) If the answer to (2) above is ignore the legacy_version, and just
> > > > use the versions in supported_versions, which client_version should
> be
> > > > used in the RSA pre-master secret calculation? The one in
> > > > legacy_version, or the highest one in supported_versions? Presumably
> > > > it has to be the one in legacy_version, otherwise thing will fail
> when
> > > > the client talks to a server that doesn't understand
> > > > supported_versions?
> > >
> > > Yeah, I presume putting the version in legacy_version is the only sane
> > > thing to do. But causes other problems with downgrade protection.
> > >
> > > OTOH, RSA key exchange is known to be very broken and is affected by
> > > all kinds of downgrade (and other) attacks. So if one wants actual
> > > security, it needs to be removed.
> > >
> >
> > We could say the versions extension only applies to 1.2 and up. I.e.
> don't
> > bother advertising 1.1 and 1.0 as a client and servers ignore 1.1 and 1.0
> > when they see them in the version list. That keeps the protocol
> deployable
> > on the Internet as it exists, avoids having to evaluate too versioning
> > schemes (if you see the extension, you don't bother reading
> legacy_version
> > at all), while avoiding the weird behavior where, given this ClientHello:
> >
> >legacy_version: TLS 1.2
> >supported_versions: {TLS 1.1}
> >
> > TLS 1.3 says to negotiate TLS 1.1 and TLS 1.2 says to negotiate TLS 1.2.
>
> So I guess you're also saying that a server that implements TLS
> 1.1 to TLS 1.3, but disables TLS 1.2 and TLS 1.3 support should
> ignore the supported_versions even when it knows about it?
>
> I guess I have same questions but with only TLS 1.3 disabled, to
> be sure when we need to look at it.
>
>
> Hrm, actually I hadn't thought of that. Yeah, I guess a server which
> disables versions must then gate supported_version handling on whether TLS
> 1.3 is enabled. That's not a dealbreaker, but is certainly additional
> gnarliness.
>
> (Our current implementation just processes the extension uncondtionally,
> but we'll also happily negotiate old versions out of it.)
>
> David
>
> ___
> 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

Re: [TLS] supported_versions question

[David Benjamin]

On Mon, Oct 31, 2016 at 6:34 PM Kurt Roeckx  wrote:

On Mon, Oct 31, 2016 at 07:11:10PM +, David Benjamin wrote:
> On Mon, Oct 31, 2016 at 2:57 PM Ilari Liusvaara 
> wrote:
>
> > On Mon, Oct 31, 2016 at 06:43:52PM +, Matt Caswell wrote:
> > > 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?
> >
> > If legacy_version > TLS1.2, the spec requires server to ignore
> > legacy_version.
> >
> > The case where legacy_version < TLS1.2 IIRC isn't specified, but
> > ignoring legacy_version is reasonable in this case too.
> >
> > > 2) What should a server do if supported_versions is received,
> > > ClientHello.legacy_version == TLS1.2, but supported_versions does not
> > > contain TLS1.3 or TLS1.2 (e.g. it contains TLS1.1 or below)? Fail the
> > > handshake, use the legacy_version, or use use the versions in
> > > supported_versions?
> >
> > There's also the case where supported_versions has TLS 1.1 and TLS 1.4,
> > the latter the server has never heard about...
> >
> > > 3) If the answer to (2) above is ignore the legacy_version, and just
> > > use the versions in supported_versions, which client_version should be
> > > used in the RSA pre-master secret calculation? The one in
> > > legacy_version, or the highest one in supported_versions? Presumably
> > > it has to be the one in legacy_version, otherwise thing will fail when
> > > the client talks to a server that doesn't understand
> > > supported_versions?
> >
> > Yeah, I presume putting the version in legacy_version is the only sane
> > thing to do. But causes other problems with downgrade protection.
> >
> > OTOH, RSA key exchange is known to be very broken and is affected by
> > all kinds of downgrade (and other) attacks. So if one wants actual
> > security, it needs to be removed.
> >
>
> We could say the versions extension only applies to 1.2 and up. I.e. don't
> bother advertising 1.1 and 1.0 as a client and servers ignore 1.1 and 1.0
> when they see them in the version list. That keeps the protocol deployable
> on the Internet as it exists, avoids having to evaluate too versioning
> schemes (if you see the extension, you don't bother reading legacy_version
> at all), while avoiding the weird behavior where, given this ClientHello:
>
>legacy_version: TLS 1.2
>supported_versions: {TLS 1.1}
>
> TLS 1.3 says to negotiate TLS 1.1 and TLS 1.2 says to negotiate TLS 1.2.

So I guess you're also saying that a server that implements TLS
1.1 to TLS 1.3, but disables TLS 1.2 and TLS 1.3 support should
ignore the supported_versions even when it knows about it?

I guess I have same questions but with only TLS 1.3 disabled, to
be sure when we need to look at it.


Hrm, actually I hadn't thought of that. Yeah, I guess a server which
disables versions must then gate supported_version handling on whether TLS
1.3 is enabled. That's not a dealbreaker, but is certainly additional
gnarliness.

(Our current implementation just processes the extension uncondtionally,
but we'll also happily negotiate old versions out of it.)

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

Re: [TLS] supported_versions question

[Kurt Roeckx]

On Mon, Oct 31, 2016 at 07:11:10PM +, David Benjamin wrote:
> On Mon, Oct 31, 2016 at 2:57 PM Ilari Liusvaara 
> wrote:
> 
> > On Mon, Oct 31, 2016 at 06:43:52PM +, Matt Caswell wrote:
> > > 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?
> >
> > If legacy_version > TLS1.2, the spec requires server to ignore
> > legacy_version.
> >
> > The case where legacy_version < TLS1.2 IIRC isn't specified, but
> > ignoring legacy_version is reasonable in this case too.
> >
> > > 2) What should a server do if supported_versions is received,
> > > ClientHello.legacy_version == TLS1.2, but supported_versions does not
> > > contain TLS1.3 or TLS1.2 (e.g. it contains TLS1.1 or below)? Fail the
> > > handshake, use the legacy_version, or use use the versions in
> > > supported_versions?
> >
> > There's also the case where supported_versions has TLS 1.1 and TLS 1.4,
> > the latter the server has never heard about...
> >
> > > 3) If the answer to (2) above is ignore the legacy_version, and just
> > > use the versions in supported_versions, which client_version should be
> > > used in the RSA pre-master secret calculation? The one in
> > > legacy_version, or the highest one in supported_versions? Presumably
> > > it has to be the one in legacy_version, otherwise thing will fail when
> > > the client talks to a server that doesn't understand
> > > supported_versions?
> >
> > Yeah, I presume putting the version in legacy_version is the only sane
> > thing to do. But causes other problems with downgrade protection.
> >
> > OTOH, RSA key exchange is known to be very broken and is affected by
> > all kinds of downgrade (and other) attacks. So if one wants actual
> > security, it needs to be removed.
> >
> 
> We could say the versions extension only applies to 1.2 and up. I.e. don't
> bother advertising 1.1 and 1.0 as a client and servers ignore 1.1 and 1.0
> when they see them in the version list. That keeps the protocol deployable
> on the Internet as it exists, avoids having to evaluate too versioning
> schemes (if you see the extension, you don't bother reading legacy_version
> at all), while avoiding the weird behavior where, given this ClientHello:
> 
>legacy_version: TLS 1.2
>supported_versions: {TLS 1.1}
> 
> TLS 1.3 says to negotiate TLS 1.1 and TLS 1.2 says to negotiate TLS 1.2.

So I guess you're also saying that a server that implements TLS
1.1 to TLS 1.3, but disables TLS 1.2 and TLS 1.3 support should
ignore the supported_versions even when it knows about it?

I guess I have same questions but with only TLS 1.3 disabled, to
be sure when we need to look at it.


Kurt

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

Re: [TLS] draft-sullivan-tls-exported-authenticator-00

[Ilari Liusvaara]

On Mon, Oct 31, 2016 at 09:29:19PM +, Nick Sullivan wrote:
>  
> draft-sullivan-tls-exported-authenticator-00>
> 
> 
> I just posted a new Internet-Draft called "Exported Authenticators in TLS"
> in the TLS working group.
> 
> The intent of this draft is to enable participants in a TLS connection to
> prove ownership of additional certificates. This differs from previous
> proposals (https://tools.ietf.org/html/draft
> -sullivan-tls-post-handshake-auth-00) in that these proofs are not sent as
> part of the TLS connection, but instead exported so that they can be sent
> out of band (as part of an application layer message, for example).
> 
> This proposal should enable a radical simplification of the Secondary
> Certificate Authentication in HTTP/2 proposal (
> https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-01),
> and should generally be a useful tool for binding a certificate ownership
> proof to a TLS connection.

This looks A LOT saner than the current post-handshake stuff in TLS 1.3
draft. Looks implementable even.

One comment about API: There should be a method to query the TLS library
capabilities with CertificateVerify algorithm verification.

The result could e.g. be list of algorithm numbers (e.g. 0403, 0503,
0603, 0804, 0805, 0806, 0807, 0808).

Also one bit unclear thing: Is RSA-PKCS1#v1.5 allowed if negotiated
TLS version is 1.2?


-Ilari

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

[TLS] draft-sullivan-tls-exported-authenticator-00

[Nick Sullivan]

draft-sullivan-tls-exported-authenticator-00>


I just posted a new Internet-Draft called "Exported Authenticators in TLS"
in the TLS working group.

The intent of this draft is to enable participants in a TLS connection to
prove ownership of additional certificates. This differs from previous
proposals (https://tools.ietf.org/html/draft
-sullivan-tls-post-handshake-auth-00) in that these proofs are not sent as
part of the TLS connection, but instead exported so that they can be sent
out of band (as part of an application layer message, for example).

This proposal should enable a radical simplification of the Secondary
Certificate Authentication in HTTP/2 proposal (
https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-01),
and should generally be a useful tool for binding a certificate ownership
proof to a TLS connection.

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

Re: [TLS] Comments on draft-ietf-tls-tls13-18

[Eric Rescorla]

Watson,

Thanks for your comments!

On Mon, Oct 31, 2016 at 11:41 AM, Watson Ladd  wrote:

> Hello,
>
> Looking at the history of TLS implementation attacks we see that many
> result from the standard not strictly enough prescribing behavior,
> particularly of the state machine. This draft does not actually fix
> this problem, but continues to present example flows without
> explicitly requiring them to be the only possible flows.
>


For example, consider HelloRetryRequest. Do servers only send one of
> these per connection, or can it be resent multiple times? Obviously
> there is a DoS possibility here, but I do not see where this behavior
> is explicitly defined. I think we should require that the server only
> ever sends one HelloRetryRequest, and then terminates the connection
> if the ClientHello is unacceptable.



The server is forbidden to send multiple HRRs and the client is required
to enforce it. See:

  https://tlswg.github.io/tls13-spec/#hello-retry-request

I agree that we don't require the server to behave this way. I can fix the
draft to say this.


At no point is it stated that only
> the example flows should be supported. I would prefer more clarity
> about what messages are to be expected when, especially with alerts.
>

Actually the text does say something here:
https://tlswg.github.io/tls13-spec/#handshake-protocol

"Protocol messages MUST be sent in the order defined below (and shown in
the diagrams in Section 2
). A peer which
receives a handshake message in an unexpected order MUST abort the
handshake with an “unexpected_message” alert. Unneeded handshake messages
are omitted, however."

However, this text was also in 5246, so I think there's a fair argument
that it's not strong enough. I'm not quite sure how to make it better.
Suggestions?


ECDSA cannot be used with x25519 or x448, but the draft seems to
> require support in TLS 1.2 for this as a consequence of its
> description of the fallback mode.


I don't *think* that that's true: can you point to the specific text that
you are concerned with?


ALPN, resumption, and 0-RTT remain problematic. For instance we see
> that 0-RTT data is sent with the same ALPN state when the PSK was
> derived, but this could be different from the ALPN transmitted and
> negotiated during the handshake, which is explicitly allowed later in
> the document. I do not understand what is supposed to happen in this
> scenario.
>

Here's the relevant text:
https://tlswg.github.io/tls13-spec/#early-data-indication

"If any of these checks fail [ALPN is in the list above] the server MUST
NOT respond with the extension and must discard all the remaining first
flight data (thus falling back to 1-RTT). If the client attempts a 0-RTT
handshake but the server rejects it, it will generally not have the 0-RTT
record protection keys and must instead trial decrypt each record with the
1-RTT handshake keys until it finds one that decrypts properly, and then
pick up the handshake from that point."

Is there anything else you'd like to see here?

Appendix B removes the text about upper-layer protocol interactions
> with 0-RTT I provided, merely discussing the API. I think this is a
> mistake: how 0-RTT should be used safely depends on the upper-layer
> protocol, and can be complex. API guidance is not enough.
>

This ended up in the main text:
https://tlswg.github.io/tls13-spec/#zero-rtt-data

"Protocols MUST NOT use 0-RTT data without a profile that defines its use.
That profile needs to identify which messages or interactions are safe to
use with 0-RTT. In addition, to avoid accidental misuse, implementations
SHOULD NOT enable 0-RTT unless specifically requested. Special functions
for 0-RTT data are RECOMMENDED to ensure that an application is always
aware that it is sending or receiving data that might be replayed."

Is this missing pieces you think we need?


There is still a note about needing a channel binding mechanism in the
> text. I think this should be resolved soon so it can be analyzed,
> probably built on top of the exporter mechanism. Either that, or we
> consciously punt and remove the note and replace with something else.
>

The idea here is that we need a separate draft that just says "use
exporters with
label X". I think we remove the note and see if we can get someone to write
that draft.


As for process, I support the idea of having a last call on November
> 20th, and then completing the security analysis by January 20th (or
> whatever date was decided). This will prevent a flurry of changes
> potentially breaking things.
>

That's the idea.

-Ekr


> Sincerely,
> Watson Ladd
>
> ___
> 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

Re: [TLS] supported_versions question

[Brian Smith]

David Benjamin  wrote:

> Ilari Liusvaara  wrote:
>
>> The case where legacy_version < TLS1.2 IIRC isn't specified, but
>> ignoring legacy_version is reasonable in this case too.
>>
>
I imagine that there will be three common implementations for the case
where legacy_version < 1.2 and supported_versions is present:

1. The server ignores supported_versions. (Note that all TLS 1.0 and TLS
1.1 implementations will do this.)
2. The server ignores legacy_version and only looks at supported_versions.
3. The server drops the connection (maybe with an alert) because clients
shouldn't be doing that in the first place.


> We could say the versions extension only applies to 1.2 and up. I.e. don't
> bother advertising 1.1 and 1.0 as a client and servers ignore 1.1 and 1.0
> when they see them in the version list. That keeps the protocol deployable
> on the Internet as it exists, avoids having to evaluate [two] versioning
> schemes (if you see the extension, you don't bother reading legacy_version
> at all), while avoiding the weird behavior where, given this ClientHello:
>
>legacy_version: TLS 1.2
>supported_versions: {TLS 1.1}
>
> TLS 1.3 says to negotiate TLS 1.1 and TLS 1.2 says to negotiate TLS 1.2.
>

David's suggestion here is reasonable and good. It definitely would be
surprising and unwanted to allow supported_versions to negotiate anything
less than TLS 1.2, especially when legacy_version is TLS 1.2.

Cheers,
Brian
-- 
https://briansmith.org/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] supported_versions question

[Xiaoyin Liu]

I think for question 1, it should ignore legacy_version, and select a version 
from supported_versions, because if a client only supports TLS 1.1 and TLS 1.3, 
in order to connect to pre-TLS1.3 server, it has to set legacy_version to TLS 
1.1.



I have no idea about questions 2 or 3.



Best,

Xiaoyin



From: Matt Caswell
Sent: Monday, October 31, 2016 2:44 PM
To: tls@ietf.org
Subject: [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 supported_versions does not
contain TLS1.3 or TLS1.2 (e.g. it contains TLS1.1 or below)? Fail the
handshake, use the legacy_version, or use use the versions in
supported_versions?

3) If the answer to (2) above is ignore the legacy_version, and just
use the versions in supported_versions, which client_version should be
used in the RSA pre-master secret calculation? The one in
legacy_version, or the highest one in supported_versions? Presumably
it has to be the one in legacy_version, otherwise thing will fail when
the client talks to a server that doesn't understand
supported_versions?

Matt

___
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

Re: [TLS] supported_versions question

[Ilari Liusvaara]

On Mon, Oct 31, 2016 at 07:11:10PM +, David Benjamin wrote:
> 
> We could say the versions extension only applies to 1.2 and up. I.e. don't
> bother advertising 1.1 and 1.0 as a client and servers ignore 1.1 and 1.0
> when they see them in the version list. That keeps the protocol deployable
> on the Internet as it exists, avoids having to evaluate too versioning
> schemes (if you see the extension, you don't bother reading legacy_version
> at all), while avoiding the weird behavior where, given this ClientHello:
> 
>legacy_version: TLS 1.2
>supported_versions: {TLS 1.1}
> 
> TLS 1.3 says to negotiate TLS 1.1 and TLS 1.2 says to negotiate TLS 1.2.

Yeah, I don't think it ever makes sense to stick TLS 1.0 or 1.1 into
supported_versions. There are good reasons to stick TLS 1.2 there tho.


-Ilari

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

Re: [TLS] supported_versions question

[Ilari Liusvaara]

On Mon, Oct 31, 2016 at 06:43:52PM +, Matt Caswell wrote:
> 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?

If legacy_version > TLS1.2, the spec requires server to ignore
legacy_version.

The case where legacy_version < TLS1.2 IIRC isn't specified, but
ignoring legacy_version is reasonable in this case too.

> 2) What should a server do if supported_versions is received,
> ClientHello.legacy_version == TLS1.2, but supported_versions does not
> contain TLS1.3 or TLS1.2 (e.g. it contains TLS1.1 or below)? Fail the
> handshake, use the legacy_version, or use use the versions in
> supported_versions?

There's also the case where supported_versions has TLS 1.1 and TLS 1.4,
the latter the server has never heard about...

> 3) If the answer to (2) above is ignore the legacy_version, and just
> use the versions in supported_versions, which client_version should be
> used in the RSA pre-master secret calculation? The one in
> legacy_version, or the highest one in supported_versions? Presumably
> it has to be the one in legacy_version, otherwise thing will fail when
> the client talks to a server that doesn't understand
> supported_versions?

Yeah, I presume putting the version in legacy_version is the only sane
thing to do. But causes other problems with downgrade protection.

OTOH, RSA key exchange is known to be very broken and is affected by
all kinds of downgrade (and other) attacks. So if one wants actual
security, it needs to be removed.



-Ilari

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

[TLS] supported_versions question

[Matt Caswell]

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 supported_versions does not
contain TLS1.3 or TLS1.2 (e.g. it contains TLS1.1 or below)? Fail the
handshake, use the legacy_version, or use use the versions in
supported_versions?

3) If the answer to (2) above is ignore the legacy_version, and just
use the versions in supported_versions, which client_version should be
used in the RSA pre-master secret calculation? The one in
legacy_version, or the highest one in supported_versions? Presumably
it has to be the one in legacy_version, otherwise thing will fail when
the client talks to a server that doesn't understand
supported_versions?

Matt

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

[TLS] draft-fossati-tls-iot-optimizations-00, 4.2, hash chain

[Kraus Achim (INST/ESY1)]

Dear Authors,

draft-fossati-tls-iot-optimizations-00 mentions in 4.2, page 5, a hash chain 
(Lampert, "Password Authentication with Insecure Communication"). 

Would it be possible, to get more details about that approach?

In my opinion, DTLS needs a connection id, the record is usually secured by the 
MAC. 
So the hash chain providing a "password" seems for me to rely on a "identity", 
for which the "password" should be verified. 
But that identity is missing and the verification is done with the MAC.

Use this in reverse, I could think of something as:

connection hash := H ^ record.sequence_number (connection id)

So with an incoming record {sequence_number, connection hash} you may look up, 
if "connection ids" hashed
"sequence_number" times results in the provided "connection hash" and then you 
may verify, if one of the
candidates will verify with the MAC.  Even with defining a "sequence number 
window" to exclude "faraway"
sessions, I'm not sure,  how such an approach would scale for a large number of 
session.

So could you please provide your ideas about that hash chain?

Mit freundlichen Grüßen / Best regards

Achim Kraus

Bosch Software Innovations GmbH
Communications (INST/ESY1)
Stuttgarter Straße 130
71332 Waiblingen
GERMANY
www.bosch-si.de
www.blog.bosch-si.com 

Tel. +49 711 811-58139
achim.kr...@bosch-si.com

Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 
148411 B
Executives: Dr.-Ing. Rainer Kallenbach; Michael Hahn


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

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

[Sean Turner]

The concern here is that people won’t review it until the end and that is 
definitely not what we want.  I’d really like get the most out of our f2f 
meeting in Seoul so pretty please people review it before Seoul.

spt

> On Oct 27, 2016, at 07:07, Salz, Rich  wrote:
> 
> So isn't it really a WGLC that runs until end of January 2017?
> 
> --  
> Senior Architect, Akamai Technologies
> Member, OpenSSL Dev Team
> IM: richs...@jabber.at Twitter: RichSalz
> 
> 
> ___
> 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

Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-09.txt

[Sean Turner]

Yoav thanks for continuing to push this. We’ll update the status slides once we 
kick off the next steps.

spt

> On Oct 29, 2016, at 16:04, Yoav Nir  wrote:
> 
> Hi.
> 
> This is mostly a maintenance version. I’ve updated references and removed 
> some TBDs for ideas that were never pursued.
> 
> IMO this is ready.
> 
> Yoav
> 
>> On 29 Oct 2016, at 23:02, internet-dra...@ietf.org wrote:
>> 
>> 
>> 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-09.txt
>>  Pages   : 32
>>  Date: 2016-10-29
>> 
>> 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 new 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-09
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-rfc4492bis-09
>> 
>> 
>> 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
> 
> ___
> 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