Unfortunately, Outlook seems to be incapable of properly quoting a message for
inline replies, so I will have to top-post with the relevant bits.
I’ll try to put together some text on side-channel resistance along with my
pull request for editorial changes.
With respect to psk_key_exchange_mode
Hi,
For draft‐mavrogiannopoulos‐dtls‐cid‐00 and we needed to extend the
DTLS un-authenticated part of the DTLS record header with an additional
field. That works well if this is the only draft ever extending the
DTLS record header. If not, modification order would be undefined.
Would it make s
Hi Nikos,
On 14/11/2016 12:58, "TLS on behalf of Nikos Mavrogiannopoulos"
wrote:
>Hi,
> For draft-mavrogiannopoulos-dtls-cid-00 and we needed to extend the
>DTLS un-authenticated part of the DTLS record header with an additional
>field. That works well if this is the only draft ever extending
Please note that I’ve been uploading the presentations as I’ve been getting
them; I’m embedding links in the chair slides to the presenters slides. The
chair slides are up to revision 4 (in case you’ve downloaded them earlier).
Still waiting on a couple.
Note that Martin will have no slides f
Please note that this draft is related to the agenda item:
- TLS Visibility Inside the Data Center
spt
> Begin forwarded message:
>
> From: internet-dra...@ietf.org
> Subject: I-D Action: draft-green-tls-static-dh-in-tls13-00.txt
> Date: November 14, 2016 at 15:36:49 GMT+9
> To:
> Reply-To: in
On 14 November 2016 at 21:58, Nikos Mavrogiannopoulos wrote:
> For draft‐mavrogiannopoulos‐dtls‐cid‐00 and we needed to extend the
> DTLS un-authenticated part of the DTLS record header with an additional
> field. That works well if this is the only draft ever extending the
> DTLS record heade
One way to split the difference between these two would be to use an
extension to negotiate the encrypted record format.
-Ekr
On Tue, Nov 15, 2016 at 9:10 AM, Martin Thomson
wrote:
> On 14 November 2016 at 21:58, Nikos Mavrogiannopoulos
> wrote:
> > For draft‐mavrogiannopoulos‐dtls‐cid‐00
On 15 November 2016 at 09:28, Eric Rescorla wrote:
> One way to split the difference between these two would be to use an
> extension to negotiate the encrypted record format.
Yes, that could work. It would need special rules for 0-RTT, but in
theory a negotiated extension could do anything to
See also PR#762
-Ekr
On Tue, Nov 15, 2016 at 9:35 AM, Martin Thomson
wrote:
> On 15 November 2016 at 09:28, Eric Rescorla wrote:
> > One way to split the difference between these two would be to use an
> > extension to negotiate the encrypted record format.
>
>
> Yes, that could work. It wou
Hello Martin,
> I've updated the test vectors draft.
>
> The vectors should now be correct with respect to draft-18. I
> implemented exporters as well, so calculations for those are now
> shown.
Thank you for very useful document.
I would be nice if this example includes secp256r1 instead of (
On 14/11/16 12:58, Nikos Mavrogiannopoulos wrote:
> Hi,
> For draft‐mavrogiannopoulos‐dtls‐cid‐00 and we needed to extend the
> DTLS un-authenticated part of the DTLS record header with an additional
> field. That works well if this is the only draft ever extending the
> DTLS record header. I
On Tue, Nov 15, 2016 at 10:10 AM, Stephen Farrell wrote:
>
>
> On 14/11/16 12:58, Nikos Mavrogiannopoulos wrote:
> > Hi,
> > For draft‐mavrogiannopoulos‐dtls‐cid‐00 and we needed to extend the
> > DTLS un-authenticated part of the DTLS record header with an additional
> > field. That works we
If I understand this draft correctly, this draft describes server behavior. It
does not change anything within the TLS 1.3 protocol. IOW a server doing this
will interoperate with any client.
I searched the tls13 draft to see if it has anything to say about this, and the
only thing I found was
On 15 November 2016 at 09:59, Kazu Yamamoto wrote:
> I would be nice if this example includes secp256r1 instead of (or in
> addition to) x25519 as I guess that many TLS 1.3 implementations
> implement secp256r1 first.
That should be easy to add. I can add a 1-RTT handshake with P-256.
In the in
On 15 November 2016 at 10:16, Eric Rescorla wrote:
>> I'd be interested in an analysis of the potential privacy
>> impacts of this. Isn't this more or less the same as doing
>> SPUD-for-DTLS? (If not, sorry for dragging in controversy:-)
>
>
> It would no doubt depend what you put there.
Which i
On 15/11/2016 03:51, "TLS on behalf of Martin Thomson"
wrote:
>On 15 November 2016 at 10:16, Eric Rescorla wrote:
>>> I'd be interested in an analysis of the potential privacy
>>> impacts of this. Isn't this more or less the same as doing
>>> SPUD-for-DTLS? (If not, sorry for dragging in controve
On Tue, 2016-11-15 at 01:10 +, Stephen Farrell wrote:
> > Would it make sense to introduce an extension header for DTLS 1.3
> > in
> > the lines of the IPv6 extension headers? That would allow TLS
> > extension
> > negotiation to add more items on the un-authenticated header, and
> > potential
Hello,
There has been a lot of chatter on Gitub about point validation. I think
it's important to note that in TLS 1.3 the Triple Handshake variants
enabled by small subgroup attacks are no longer a threat: the issue is
reuse of ephemeral Diffie-Hellman exponents, resulting in compromise of
what i
On Tue, 2016-11-15 at 09:10 +0900, Martin Thomson wrote:
> On 14 November 2016 at 21:58, Nikos Mavrogiannopoulos m> wrote:
> >
> > For draft‐mavrogiannopoulos‐dtls‐cid‐00 and we needed to extend
> > the
> > DTLS un-authenticated part of the DTLS record header with an
> > additional
> > field.
On 15 November 2016 at 16:12, Nikos Mavrogiannopoulos wrote:
> TLDR; the privacy offered by this extension is the same as the privacy
> of DTLS over UDP.
I disagree. All the privacy considerations of the QUIC connection ID
apply here. It would probably pay to follow that discussion.
If the int
On Mon, Nov 14, 2016 at 11:36 PM, Martin Thomson
wrote:
> On 15 November 2016 at 16:12, Nikos Mavrogiannopoulos wrote:
>> TLDR; the privacy offered by this extension is the same as the privacy
>> of DTLS over UDP.
>
> I disagree. All the privacy considerations of the QUIC connection ID
> apply h
On Tue, Nov 15, 2016 at 4:16 PM, Watson Ladd wrote:
> Hello,
>
> There has been a lot of chatter on Gitub about point validation. I think
> it's important to note that in TLS 1.3 the Triple Handshake variants
> enabled by small subgroup attacks are no longer a threat: the issue is
> reuse of ephe
22 matches
Mail list logo
