The following errata report has been submitted for RFC7250,
"Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)".
--
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5013
I would definitively re-categorize this “editorial”; there’s no 2119-changes
proposed and there’s no bits on the wire changes. And, I’d either reject this
one because technically the existing text is correct (i.e., they are two
extensions) and this really ought not of caused an interoperability
On Wed, 10 May 2017, Sean Turner wrote:
I would definitively re-categorize this “editorial”; there’s no 2119-changes
proposed and there’s no bits on the wire changes. And, I’d either reject this
one because technically the existing text is correct (i.e., they are two
extensions) and this rea
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
Yes, encrypted SNI was discussed and ultimately rejected.
But do we really have to send the literal value? Don't we need to just make
sure that the client and server agree on the host that the client wants to
connect?
Couldn't we "encrypt" the SNI by hashing the host name with a salt, sending
> On May 10, 2017, at 1:28 PM, Hubert Kario wrote:
>
> Couldn't we "encrypt" the SNI by hashing the host name with a salt, sending
> the salt and the resulting hash, making the server calculate the same hash
> with each of the virtual host names it supports and comparing with the client
> pro
On Wednesday, 10 May 2017 20:25:22 CEST Viktor Dukhovni wrote:
> > On May 10, 2017, at 1:28 PM, Hubert Kario wrote:
> >
> > Couldn't we "encrypt" the SNI by hashing the host name with a salt,
> > sending
> > the salt and the resulting hash, making the server calculate the same hash
> > with each
> On May 10, 2017, at 2:47 PM, Hubert Kario wrote:
>
> But in general, I wonder if we didn't approach the SNI from the wrong side -
> as I said, we may not need to encrypt it, we just make sure that client and
> server agree on the virtual host the connection is going to.
They can do that wit
> Encryption means key agreement, and requires delaying SNI by a round-trip,
> or having published DH shares in DNS, which of course also needs privacy
> protection for SNI encryption to matter.
With TLS1.3 encryptedExtensions, secure "domain fronting" becomes possible.
A am long overdue for a
On 5/10/2017 12:04 PM, Viktor Dukhovni wrote:
>> On May 10, 2017, at 2:47 PM, Hubert Kario wrote:
>>
>> But in general, I wonder if we didn't approach the SNI from the wrong side -
>> as I said, we may not need to encrypt it, we just make sure that client and
>> server agree on the virtual hos
On 05/10/2017 02:12 PM, Christian Huitema wrote:
>
> On 5/10/2017 12:04 PM, Viktor Dukhovni wrote:
>>> On May 10, 2017, at 2:47 PM, Hubert Kario wrote:
>>>
>>> But in general, I wonder if we didn't approach the SNI from the wrong side
>>> -
>>> as I said, we may not need to encrypt it, we just m
On Wed, May 10, 2017 at 07:28:51PM +0200, Hubert Kario wrote:
> Yes, encrypted SNI was discussed and ultimately rejected.
>
> But do we really have to send the literal value? Don't we need to just make
> sure that the client and server agree on the host that the client wants to
> connect?
>
> C
On 11 May 2017 at 01:21, Matt Caswell wrote:
> Do we really need all of these alerts?
NSS uses these, but in ways that I don't really understand. I think
that this is part of the general issue that TLS does and doesn't
really include requirements about how to handle the certificate chain.
_
The SNI extension is optional, so you don't have to send the literal
value. Indeed quite some number of apps do not send it. Browsers
currently can't know if the SNI is required by the origin servers and
usually send this, but there could be some signal to not send it. One
example could be a HT
On 5/10/2017 2:40 PM, Roland Zink wrote:
> The SNI extension is optional, so you don't have to send the literal
> value. Indeed quite some number of apps do not send it. Browsers
> currently can't know if the SNI is required by the origin servers and
> usually send this, but there could be some s
Not necessarily as you may for example use the path part of a URL to
distinguish between services.
Roland
Am 10.05.2017 um 23:50 schrieb Christian Huitema:
On 5/10/2017 2:40 PM, Roland Zink wrote:
The SNI extension is optional, so you don't have to send the literal
value. Indeed quite so
On Wed 2017-05-10 12:12:34 -0700, Christian Huitema wrote:
> It certainly was. But then the clear text SNI is a gaping privacy hole
> in TLS, the kind of issue that should keep us awake at night until it is
> resolved. We need to make sure that we make progress, rather than rehash
> the old argumen
As Ilari says, there's a lot of stuff in here. I'll put some thoughts
here at the top, and more inline.
First off, it seems somewhat self-evident that if we guarantee 0-RTT
non-replay, then of course it makes sense to just concatenate the
streams. That is, if 0-RTT data is not replayable, there'
On Wed, May 10, 2017 at 10:00 PM, Benjamin Kaduk wrote:
>
> However, I'm still not convinced that requiring strong 0-RTT non-replay is
> feasible/the right thing to do.
>
[ I've cut a lot for brevity, but hopefully what I've replied with can
address this, and the rest ]
The case for requiring se
19 matches
Mail list logo
