Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt)

2018-05-31 Thread Steven Valdez 
We might also want to mark 40 similarly given the ExtendedRandom collision
that caused issues with key_share.

On Thu, May 31, 2018 at 11:10 AM Benjamin Kaduk  wrote:

> I think there's also some room to just mark 26 as "Reserved - unauthorized
> use has rendered this value unsuitable for official allocation".
>
> -Ben
>
> On Thu, May 31, 2018 at 07:50:46AM -0700, Eric Rescorla wrote:
> > Based on this, I propose that IANA allocates a new !26 Early Data code
> > point for compressed certificates (that's mechanical).
> >
> > As noted earlier, it's premature for TLS-LTS to request a code point
> > because the enabling document has not yet been published, so we can defer
> > the question of its use of 26 for a bit.
> >
> > The QUIC TLS extension should also change to a new code point, but I'm
> not
> > sure it meets the criteria for an early code point assignment. MT
> proposed
> > just squatting on a random code point. Having a really unique code point
> is
> > less important here because this extension will only appear inside of
> QUIC
> > and not on ordinarily TLS connections, though of course it must have a
> > unique code point from other extensions used with QUIC. So it's not
> > entirely clear how best to handle this,
> >
> > -Ekr
> >
> >
> > On Thu, May 31, 2018 at 7:42 AM, David Benjamin 
> > wrote:
> >
> > > I probed a bunch of servers yesterday and found evidence of yet another
> > > collision at 26! It's possible these are TLS-LTS implementations, but
> a lot
> > > of them additionally only support RSA decryption ciphers, which makes
> this
> > > seem unlikely. These servers do not appear to do anything with the
> > > extension, as far as I could tell, including even echoing it back, but
> > > they  send decode_error if the extension includes a non-empty body.
> (It's
> > > possible their TLS implementation supports TLS-LTS, unconditionally
> parses
> > > the extension, but does not actually enable it by default.)
> > >
> > > I didn't repeat the probe with 27, but playing with a couple of the
> > > servers showed they tolerate other numbers fine, including 27. It's
> just
> > > that they appear to have squatted on 26 for something.
> > >
> > > It's frustrating that allocating code points is complicated, but given
> the
> > > other deployment problems TLS has seen lately, were this the worst of
> our
> > > problems, I would be quite happy.
> > >
> > > On Thu, May 31, 2018 at 1:56 AM Joseph Salowey 
> wrote:
> > >
> > >> I agree we should use a different number than 26 for certificate
> > >> compression.  I don't see a problem with assigning 27 and reserving
> 26 for
> > >> now.
> > >>
> > >> On Wed, May 30, 2018 at 8:13 PM, Adam Langley  >
> > >> wrote:
> > >>
> > >>> On Tue, May 29, 2018 at 6:16 PM Jeffrey Walton 
> > >>> wrote:
> > >>> > I also delivered an OpenSSL-based TLS-LTS prototype to a Hoteliers
> > >>> > working group for their smart locks last year. I have no idea how
> much
> > >>> > of the code they are going to reuse (if any at all).
> > >>>
> > >>> Chrome / Google is blocked on code-point assignment for deploying
> > >>> certificate compression. It appears that 26 is not a good pick and we
> > >>> thus wait in anticipation for a replacement.
> > >>>
> > >>> (The extensions space is effectively infinite: if we get close to
> > >>> running out, we can assign an "extended extensions" code point, which
> > >>> would contain a nested extensions block with 32-bit numbers instead.
> > >>> Therefore effort and delays resulting from treating it as a scarce
> > >>> resource are saddening. Speaking in a personal capacity, it looks
> like
> > >>> 26 is TLS-LTS, maybe 27 for compression? Or else we could assign them
> > >>> randomly to avoid issues with concurrent applications and I offer
> > >>> 0xbb31 as a high-quality, random number. Since we had a triple
> > >>> collision in this case, random-assignment's virtues are currently
> > >>> particularly clear.)
> > >>>
> > >>> --
> > >>> Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
> > >>>
> > >>
> > >> ___
> > >> 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
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


-- 

Steven Valdez |  Chrome Networking |  sval...@google.com |  210-692-4742
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Draft 18 review : Hello Retry Request and supported groups cache

2016-11-22 Thread Steven Valdez 
Being able to send supported_groups does allow a server to choose to make a
tradeoff between an extra round trip on the current connection and its own
group preferences. One example where a server might want to do this is
where it believes that X25519 is likely a more future-proof group and would
prefer that, but still believes the client's choice of P256 is suitable for
this connection. Always requiring an extra round trip might end up being
expensive depending on the situation so some servers might prefer to avoid
sending an HRR for a slightly more preferred group.

I think that requiring the client to maintain state from the
supported_groups puts undue requirements on the client, since not all
clients keep state between connections, and those that do usually only keep
session state for resumption.

On Tue, Nov 22, 2016 at 2:01 PM Olivier Levillain <
olivier.levill...@ssi.gouv.fr> wrote:

> Hi list,
>
> I am sorry for the very late answer concerning draft 18, but we
> (ANSSI) have several remarks after proof-reading the current
> specification.
>
> We are sorry for the multiple long messages.
>
> If the WG is interested by some of our concerns/proposals, we would be
> glad to propose some PRs.
>
>
> = HRR and supported groups cache =
>
> In 4.2.4 (P.41), a server can send a supported_groups extension to
> "update the client's view of its preference" in its ServerHello.
> Since this behaviour is completely left to the client's discretion, it
> does not seem a very relevant policy from the server: either the
> server accepts one of the proposed groups, or it sends an HRR.  We do
> not think the middle ground (OK for this group, but I would prefer
> this other one) is relevant, so the sentence should be removed.
>
> Moreover, as far as I could understand, there is no indication in the
> specification that a client should remember the preference of the
> server in case it receives a HRR, which there would definitely make
> sense.  Such text could go in 4.1.4.
>
> I can propose a PR for this point.
>
>
> Olivier Levillain
>
> ___
> 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] Confirming consensus: TLS1.3->TLS*

2016-11-19 Thread Steven Valdez 
Maintaining my hum from the meeting, I prefer keeping TLS 1.3 over
renaming, primarily because there's now a good amount of
documentation/implementation in the wild that refers to TLS 1.3, and we'll
need to keep around the new equivalence of TLS 2 (or 4)=TLS 1.3.


On Sat, Nov 19, 2016, 8:31 AM Ira McDonald  wrote:

> Hi,
>
> I think that the presumption that most tech people (or even security
> people)
> won't have any trouble with the future version numbering of TLS is wrong.
>
> Yesterday morning, on an SAE Vehicle Electrical Systems Security call with
> some 40 auto security professionals present, I mentioned that TLS 1.3 was
> wrapping up and was asked "What's TLS?"  Usual explanation about SSL
> being succeeded by IETF TLS 17 years ago.  Several responses that were
> the equivalent of blank stares.  And finally, "Then why is the library
> still
> called OpenSSL?"
>
> Rich has highlighted that the tech community goes right on conflating SSL
> with TLS on web sites.
>
> I change my two cents to "TLS 4" but am unsure about "4" or "4.0" because
> the tech community has been trained to care about major.minor.
>
> Cheers,
> - Ira
>
>
> Ira McDonald (Musician / Software Architect)
> Co-Chair - TCG Trusted Mobility Solutions WG
> Chair - Linux Foundation Open Printing WG
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music / High North Inc
> http://sites.google.com/site/blueroofmusic
> http://sites.google.com/site/highnorthinc
> mailto: blueroofmu...@gmail.com
> Jan-April: 579 Park Place  Saline, MI  48176  734-944-0094
> May-Dec: PO Box 221  Grand Marais, MI 49839  906-494-2434
>
>
> On Sat, Nov 19, 2016 at 6:32 AM, Jeffrey Walton 
> wrote:
>
> On Thu, Nov 17, 2016 at 9:12 PM, Sean Turner  wrote:
> > At IETF 97, the chairs lead a discussion to resolve whether the WG
> should rebrand TLS1.3 to something else.  Slides can be found @
> https://www.ietf.org/proceedings/97/slides/slides-97-tls-rebranding-aka-pr612-01.pdf
> .
> >
> > The consensus in the room was to leave it as is, i.e., TLS1.3, and to
> not rebrand it to TLS 2.0, TLS 2, or TLS 4.  We need to confirm this
> decision on the list so please let the list know your top choice between:
> >
> > - Leave it TLS 1.3
> > - Rebrand TLS 2.0
> > - Rebrand TLS 2
> > - Rebrand TLS 4
> >
> > by 2 December 2016.
>
> Please forgive my ignorance...
>
> Who are you targeting for the versioning scheme? Regular users? Mom
> and pop shops with a web presence? Tech guys and gals? Security folks?
>
> For most tech people and security folks, I don't think it matters
> much. However, how many regular users would have clung to SSLv3 and
> TLS 1.0 (given TLS 1.2 was available) if they were named SSL 1995 and
> TLS 1999 (given TLS 2008 or TLS 2010 was available)?
>
> (Sorry to violate the Hum restriction).
>
> Jeff
>
> ___
> 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