The TLS draft after version -21 requires TLS1.3 servers to negotiate
pre-TLS1.3 versions with a new, mechanism. The document states:
"If this extension is present, servers MUST ignore the
ClientHello.legacy_version value and MUST use only the
"supported_versions" extension to determine cl
On Thu, Mar 1, 2018 at 5:24 AM, Nikos Mavrogiannopoulos
wrote:
> The TLS draft after version -21 requires TLS1.3 servers to negotiate
> pre-TLS1.3 versions with a new, mechanism. The document states:
>
>"If this extension is present, servers MUST ignore the
>ClientHello.legacy_version val
I’ve submitted the following PR to make sure we answer IANA questions*:
https://github.com/tlswg/tls13-spec/pull/1159
One thing I’d like to get input on is which of the RSA-PSS signature schemes
should be recommended. The IANA considerations currently recommends
rsa_pss_sha256, rsa_pss_sha384,
I believe you are misinterpreting the text, but agree that it could be
made more clear.
Suppose that the ClientHello includes a supported_versions extensions
that contains two values, TLS 1.4 and TLS 1.0, and the server supports
TLS 1.3 and below. My interpretation of the current draft is t
FWIW, this was BoringSSL's interpretation as well. We don't consider
supported_versions an acceptable TLS 1.2 (or earlier) ServerHello
extension. I generally agree that we shouldn't add new unnecessary
combinations.
(TBH, I don't even consider the ability to advertise TLS 1.3 and TLS 1.1 on
the cl
On Thu, Mar 1, 2018 at 10:42 AM, David Benjamin
wrote:
> FWIW, this was BoringSSL's interpretation as well. We don't consider
> supported_versions an acceptable TLS 1.2 (or earlier) ServerHello
> extension. I generally agree that we shouldn't add new unnecessary
> combinations.
>
So, I think the
On Wed, Feb 28, 2018 at 3:07 PM, Nico Williams
wrote:
> IF there's an objection to modifying the extension in order to add a
> pin-to-DANE TTL field, I would propose the following instead:
>
> Make the pin-to-DANE be "forever" but make it so it can easily be
> cleared if DANE is undeploye
On Tue, Feb 27, 2018 at 6:36 PM, Nico Williams
wrote:
> On Tue, Feb 27, 2018 at 11:24:31AM -0500, Shumon Huque wrote:
> > On Tue, Feb 27, 2018 at 10:59 AM, Shumon Huque wrote:
> > > Several of us were well aware of this during the early days of the
> > > draft, but perhaps many folks did not ful
I should note that Ben pointed out in the PR that we might need to specify all
6 as recommended. I can kind of get behind that because before we were doing
PSS regardless of the identifier. Thoughts?
spt
> On Mar 1, 2018, at 09:58, Sean Turner wrote:
>
> I’ve submitted the following PR to m
To expound a bit more on my thinking, pss_pss is what we actually want
people to be using, thus it should be Recommended, but pss_rsae is what
people are actually going to be using (to large extent), and that is
still a deployment that we consider good and useful, for now. Maybe in
5 years the IES
On Fri, Mar 2, 2018 at 7:32 AM, Benjamin Kaduk wrote:
> To expound a bit more on my thinking, pss_pss is what we actually want
> people to be using, thus it should be Recommended, but pss_rsae is what
> people are actually going to be using (to large extent), and that is
> still a deployment that
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
I would like to get comments on this Internet-Draft. Once a round of comments
have been received and folded into -01, I would like to work with folks that
did the earlier proofs with Tamarin to make sure that the this does not
negatively impact the TLS 1.3 protocol changes that were made to eli
> On Mar 1, 2018, at 2:13 PM, Shumon Huque wrote:
>
>> On Wed, Feb 28, 2018 at 3:07 PM, Nico Williams wrote:
>> IF there's an objection to modifying the extension in order to add a
>> pin-to-DANE TTL field, I would propose the following instead:
>>
>>Make the pin-to-DANE be "forever" but
Hi,
I've been analysing the record protocol spec for TLS 1.3 a bit, specifically
the new padding mechanism. I think there's a possible timing attack on a naïve
implementation of de-padding. Maybe this is already known to people who've been
paying more attention than me!
Recall that the padding
Hi Russ,
This seems like a welcome addition. I'm not sure why you think that
PQ needs are a good motivation for this work though. Managing
external PSKs is so unwieldy that it almost seems like this would do
more harm than good in that regard. I find this more interesting from
the perspective o
Martin:
>
> This seems like a welcome addition. I'm not sure why you think that
> PQ needs are a good motivation for this work though. Managing
> external PSKs is so unwieldy that it almost seems like this would do
> more harm than good in that regard. I find this more interesting from
> the pe
Hi Kenny,
Yes, this is something we are aware of. Here's the relevant text from the
document:
https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#rfc.appendix.E.3
I don't think we're likely to change the protocol, but if you have some
proposed text
that you think would be informative abo
Hi Ekr.
Ah that's great, thanks - and I think the text in the Appendix already
addresses the issues very well.
Sorry for the bandwidth consumption.
Cheers,
Kenny
-Original Message-
From: Eric Rescorla
Date: Thursday, 1 March 2018 at 22:27
To: "Paterson, Kenny"
Cc: "tls@ietf.org"
S
There's another, more cache-friendly approach too, which is to record the
position of the highest non-zero byte as the decryption occurs (while that
cache-line of plaintext is still in-cache) in-order. I found that a bit
easier to implement in constant time too because it's easy to generate an
all-
The data ultimately needs to be returned to the calling application,
presumably some HTTP parser, which in turn passes data up to more calling
code and so on. Conversely, the data must have been produced by some also
application-level process on the sender, some HTTP serializer, before it
was hande
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.
Title : SNI Encryption in TLS Through Tunneling
Authors : Christian Huitema
Eric Re
> On Mar 1, 2018, at 16:31, Martin Thomson wrote:
>
> On Fri, Mar 2, 2018 at 7:32 AM, Benjamin Kaduk wrote:
>> To expound a bit more on my thinking, pss_pss is what we actually want
>> people to be using, thus it should be Recommended, but pss_rsae is what
>> people are actually going to be usi
On Thu 2018-03-01 21:52:51 +, Paterson, Kenny wrote:
> I think there's a possible timing attack on a naïve implementation of
> de-padding.
Thanks for observing this, Kenny! I think this came up when we were
designing the padding originally, and iirc, the general consensus was:
(a) this sche
I think that I was suggesting this:
The following values SHALL be marked as
"Recommended": ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384,
rsa_pss_rsae_sha256, rsa_pss_rsae_sha384,rsa_pss_rsae_sha512,
rsa_pss_pss_sha256, rsa_pss_pss_sha384,rsa_pss_pss_sha512, and
ed25519.
On Fri, Mar 2,
On Fri, Mar 2, 2018 at 10:23 AM, Daniel Kahn Gillmor
wrote:
> You could of course check from the front of the plaintext, keeping every
> non-zero value:
>
> char ptype = 0;
> for (i = 0; i < plaintext_len; i++)
> if plaintext[i]
> ptype = plaintext[i];
What about ?
size_t l[2];
siz
On Thu, Mar 1, 2018 at 5:12 PM, Martin Thomson
wrote:
> On Fri, Mar 2, 2018 at 10:23 AM, Daniel Kahn Gillmor
> wrote:
> > You could of course check from the front of the plaintext, keeping every
> > non-zero value:
> >
> > char ptype = 0;
> > for (i = 0; i < plaintext_len; i++)
> > if pl
On Fri, Mar 2, 2018 at 12:17 PM, Eric Rescorla wrote:
> This is fun, but I want to note that many (most) APIs are not zero-copy but
> rather involve
> SSL_Read() copying data from some internal buffer into a caller supplied
> buffer. So
> that operation also needs to be made constant time (e.g., b
Okay that was a fail on my part I meant to put all 6 in. Updated the PR.
spt
> On Mar 1, 2018, at 20:05, Martin Thomson wrote:
>
> I think that I was suggesting this:
>
> The following values SHALL be marked as
> "Recommended": ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384,
> rsa_pss_rsae
29 matches
Mail list logo
